Real-time DEX and on-chain data across 36 blockchains: liquidity pools, token prices, OHLCV, transactions, and cross-chain search. 17 keyless tools.
Get 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, price_change_percentage_24h_min/max, 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 | |
| price_change_percentage_24h_max | No | OPTIONAL: Maximum 24h price change, in percent | |
| price_change_percentage_24h_min | No | OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds tokens down at least 20%. This is the only price-change window tokens carry; for 6h, 1h or 5m use getNetworkPoolsFilter. |
| Name | Required | Description |
|---|---|---|
| query | No | Echo of the resolved query and filters the API applied. |
| results | Yes | |
| next_cursor | No | Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page. |
| has_next_page | No | True if more results are available; fetch them by passing next_cursor as `cursor`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the bar is lower. The description still adds meaningful behavior: keyless access, results wrapped under 'results' with has_next_page and next_cursor, AND-combined filters, defaults, and alias behavior. This is exactly the kind of contextual detail an agent needs beyond the safety profile.
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-organized: purpose, safety, selection guidance, usage examples, filter semantics, and core parameter behavior. Each sentence earns its place, and key decision information is front-loaded ahead of the parameter summary.
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 19-parameter surface, the rich schema, and output schema, the description covers all critical operational aspects: required network, pagination mechanics, defaults, aliases, filter combination, and the boundary of what price-change windows are available. The pointer to getNetworkPoolsFilter for other windows closes a likely agent misconception.
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. The description adds value beyond the schema by explaining AND-combination semantics, Unix timestamp format, canonical-vs-alias naming, and default values. It could have enumerated the filter semantics even further, but it already meaningfully augments 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?
Description states a specific verb and resource ('Get tokens on one network matching numeric thresholds'), names the response shape, and explicitly differentiates itself from getTopTokens. The examples tie concrete user requests to the tool, making its purpose unmistakable.
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 guidance is provided: 'Choose this over getTopTokens when the user gives numeric constraints or a time window,' followed by realistic example queries. It also notes in the schema where to go for non-24h price-change windows, giving the agent both selection and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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. |
| Name | Required | Description |
|---|---|---|
| stats | Yes | |
| server | Yes | |
| workflows | Yes | Named tool sequences for common agent tasks. |
| agent_skills | Yes | |
| documentation | Yes | |
| common_pitfalls | Yes | Known edge cases agents should be aware of. |
| network_synonyms | Yes | Canonical network id -> common alternates an agent might try. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds beyond these by stating the tool is 'keyless', returns static onboarding docs rather than live data, and is intended to be read once at session start. This gives useful 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 every sentence earns its place: purpose and contents are front-loaded, usage triggers are explicit, alternatives are named, and the parameter note closes it out. No filler or repetition of schema details.
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 single-parameter read-only tool with a rich annotation set and an output schema, the description covers everything an agent needs: what the tool returns, when to call it, how to distinguish it from siblings, and the only parameter requirement. Nothing important is missing.
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 fully documents the `rationale` parameter including length constraints and privacy guidance. The description only adds 'Takes no parameters beyond a short rationale,' which is marginal but not necessary given the schema's completeness.
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 identifies a specific verb and resource: 'Get the static agent onboarding guide for this server' and enumerates its contents (workflows, network name synonyms, call sequences, pitfalls). It also explicitly distinguishes itself from siblings by noting this is not live market data and pointing to getNetworks and getStats for those needs.
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 guidance: 'Read it once at the start of a session before your first query, or when asked...' and lists concrete natural-language triggers. It also names alternatives (getNetworks, getStats) and explains what this tool should not be used for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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. |
| Name | Required | Description |
|---|---|---|
| query | No | Echo of the resolved query and filters the API applied. |
| results | Yes | |
| next_cursor | No | Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page. |
| has_next_page | No | True if more results are available; fetch them by passing next_cursor as `cursor`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive, but the description adds substantial behavioral context: the tool is keyless, proxies a search endpoint, the old endpoint was removed, the 24h volume field was renamed, page_info no longer exists, wrong dex_name returns HTTP 200 with empty results rather than an error, and page numbers are superseded by cursor pagination. This goes well beyond what annotations provide and contains no contradictions.
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 and examples, and every major segment earns its place: scope, use cases, the critical dex_id/dex_name pitfall, and pagination behavior. It is long, but the density of useful operational detail justifies most of it. It loses a point because the final 'Params' section largely duplicates the schema's own parameter descriptions.
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 10 parameters, multiple aliases, a legacy endpoint change, a subtle empty-results failure mode, and cursor pagination, this description is remarkably complete. Together with the rich input schema, annotations, and existing output schema, an agent has everything needed to call it correctly and interpret edge cases.
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 baseline is 3. The description summarizes defaults, aliases, and the dex_id-vs-dex_name gotcha, but these details already appear in the input schema itself. It adds no genuinely new parameter meaning beyond what the schema already documents.
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 the pools belonging to one specific DEX on one network', with a concrete Uniswap v3/ethereum example. It also distinguishes itself from the sibling getNetworkPools by explicitly noting it is narrower and covers a single exchange, not the whole chain.
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 gives explicit use cases ('show me Raydium pools', 'top pairs on PancakeSwap') and directly compares against getNetworkPools. It also gives a clear prerequisite workflow: get the dex_id from getNetworkDexes or search first, and warns against passing dex_name. This gives an agent concrete decision rules for when and how to call the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the DEXes (exchanges) operating on one network, such as Uniswap on ethereum or Raydium on solana, returned under 'dexes' with page_info (page, total_pages). Read-only and keyless. Use for 'which DEXes are on Base?', 'does Solana have Orca?', or to get a dex id to feed into getDexPools. Scope is a single network; call getNetworks first for the slug. Params: network (required slug); limit (default 10, max 100); page (default 1, 1-indexed); sort_by (only 'pool'; legacy alias order_by); sort_dir 'asc' or 'desc' (default 'desc'; legacy alias sort).
| 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. |
| Name | Required | Description |
|---|---|---|
| dexes | Yes | |
| page_info | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint, idempotentHint, non-destructive), and the description adds substantial context beyond them: 'keyless' states auth requirements, and it reveals the return shape ('returned under dexes with page_info (page, total_pages)') plus default values and legacy alias behavior. No contradiction with annotations — 'Read-only' aligns with readOnlyHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause, followed by compact behavioral, usage, prerequisite, and routing notes. The trailing param enumeration is dense and readable as a quick-reference, though it partially duplicates a schema that already fully documents every parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, rich annotations, and 100% schema parameter coverage, the description covers the remaining ground: when to call, concrete example queries, prerequisite and downstream tools, auth posture, return envelope, and defaults. No material gap remains for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's param summary (defaults, alias pairs sort_by/order_by and sort_dir/sort) is convenient, but that same information already lives in each schema property description, so it adds convenience rather than new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the DEXes (exchanges) operating on one network') with concrete examples (Uniswap on ethereum, Raydium on solana). The single-network scope and the pointer to getDexPools as the downstream consumer distinguish it from getNetworkPools and getDexPools without requiring an agent to open any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly enumerates the query intents it serves ('which DEXes are on Base?', 'does Solana have Orca?') and the downstream use ('to get a dex id to feed into getDexPools'). It also names the prerequisite step ('call getNetworks first for the slug'), giving an agent a complete routing path across siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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. |
| Name | Required | Description |
|---|---|---|
| query | No | Echo of the resolved query and filters the API applied. |
| results | Yes | |
| next_cursor | No | Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page. |
| has_next_page | No | True if more results are available; fetch them by passing next_cursor as `cursor`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses keyless access, pagination semantics via has_next_page and next_cursor with cursor chaining, and default sorting behavior. It also explains canonical parameter names and REST-layer aliases, giving the agent a clear behavioral model. No contradiction with the existing 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 and default ranking, then moves through examples, alternative tools, and a compact parameter summary. Each sentence adds operational information, and there is no filler or wasted wording.
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?
It covers purpose, auth requirements, default behavior, pagination, parameter conventions, and sibling routing. Combined with a fully described input schema and an output schema, an agent has the information needed to select and call the tool correctly; the only omitted required param, rationale, is fully specified in the schema.
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%, and the description's parameter summary largely restates what the input schema already documents for network, limit, cursor, sort_by, and sort_dir. It is a useful overview but adds little semantic meaning beyond the schema's detailed 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, and scope: get top liquidity pools across an entire network, ranked by 24h volume by default. It further positions itself as the 'primary chain-wide pool discovery tool' and names the sibling tools that cover narrower cases, making sibling differentiation immediate.
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 gives concrete natural-language triggers ('biggest pools on ethereum', 'top trading pairs on Base', 'most active pools on Solana') and explicit routing guidance: narrow to one exchange with getDexPools, or apply numeric/time filters with getNetworkPoolsFilter. This is direct when-to-use and when-not-to-use instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pools on one network filtered by numeric thresholds, returned under 'results' with has_next_page and next_cursor. Read-only and keyless. Choose this over getNetworkPools when the user gives numeric constraints or a time window. Use for 'pools over $1M liquidity on Base', 'pools created in the last 24h', or 'high-volume low-liquidity pairs'. Optional filters (AND-combined): volume_24h_min/max, volume_7d_min/max, liquidity_usd_min/max, txns_24h_min, price_change_percentage_{24h,6h,1h,5m}_min/max (percent, negatives allowed), 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 | |
| price_change_percentage_1h_max | No | OPTIONAL: Maximum 1h price change, in percent | |
| price_change_percentage_1h_min | No | OPTIONAL: Minimum 1h price change, in percent | |
| price_change_percentage_5m_max | No | OPTIONAL: Maximum 5m price change, in percent | |
| price_change_percentage_5m_min | No | OPTIONAL: Minimum 5m price change, in percent. The shortest window we carry, so it is the one to reach for on 'what is moving right now'. | |
| price_change_percentage_6h_max | No | OPTIONAL: Maximum 6h price change, in percent | |
| price_change_percentage_6h_min | No | OPTIONAL: Minimum 6h price change, in percent | |
| price_change_percentage_24h_max | No | OPTIONAL: Maximum 24h price change, in percent | |
| price_change_percentage_24h_min | No | OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds pools down at least 20%. |
| Name | Required | Description |
|---|---|---|
| query | No | Echo of the resolved query and filters the API applied. |
| results | Yes | |
| next_cursor | No | Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page. |
| has_next_page | No | True if more results are available; fetch them by passing next_cursor as `cursor`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, so the description adds value by noting keyless access, the response shape ('results' with has_next_page and next_cursor), and AND-combined filtering semantics. It goes beyond what annotations provide 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded, leading with purpose, usage guidance, and examples before enumerating parameters. It is long, but proportionally so given 25 parameters, and the compact grouped filter listing avoids repeating every schema description verbatim.
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 complex 25-parameter tool, the description covers selection criteria, filter semantics, defaults, aliases, pagination, return shape, auth requirements, and concrete examples. Combined with a rich output schema and complete annotations, nothing essential is missing for an agent to invoke it 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 the baseline is 3. The description adds non-obvious semantics beyond the schema: filters are AND-combined, price-change negatives are permissive, sort_by/order_by and sort_dir/sort are aliases, and defaults are reiterated for quick scanning. This is meaningful added value rather than mere repetition.
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 pools on one network filtered by numeric thresholds') and immediately differentiates itself from getNetworkPools by stating when this variant is preferred. Example queries make the tool's purpose unmistakable.
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 directs the agent to choose this tool over getNetworkPools when numeric constraints or a time window are present, with concrete example user phrasings. This is strong when-to-use guidance with a named alternative and a clear exclusion condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List 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. |
| Name | Required | Description |
|---|---|---|
| networks | Yes | All supported blockchain networks with current 24h volume + indexing stats. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints, and the description adds useful behavioral details beyond those: it states 'keyless' access, 'returns the full array with no pagination or sorting,' and that no parameters besides rationale are accepted. This goes beyond the structured 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is packed with high-value information—purpose, return fields, keyless access, usage examples, and a cross-reference to getStats—while remaining compact. Every sentence contributes to either selection, invocation, or interpretation of the tool; there is no filler.
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 list tool with a single required parameter and an output schema, the description fully covers what the agent needs: what the result contains, how to obtain the network slug for downstream calls, pagination/sorting behavior, and the alternative for platform-wide statistics. Nothing critical is missing.
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?
The schema already documents the single rationale parameter with a clear description (coverage 100%), and the description reiterates 'takes no parameters beyond a short rationale.' This adds marginal clarity but does not materially extend what the schema provides, so 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 begins with a specific verb and resource: 'List every blockchain network DexPaprika indexes,' and enumerates the exact data fields (slug, volume, transaction count, pool count). It distinguishes itself from getStats and getCapabilities, so an agent can clearly tell what this tool does and what it does not.
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?
Gives explicit when-to-use guidance: 'Start here (or getCapabilities) to get the exact network slug that nearly every other tool requires' and provides concrete example queries like 'is Base/Solana/Arbitrum covered?'. It also names the alternative getStats for platform-wide totals, offering both inclusion and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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') |
| Name | Required | Description |
|---|---|---|
| id | No | |
| fee | No | |
| chain | No | |
| dex_id | No | |
| tokens | No | |
| dex_name | No | |
| created_at | No | |
| factory_id | No | |
| last_price | No | |
| price_time | No | |
| price_stats | No | |
| last_price_usd | No | |
| token_reserves | No | |
| created_at_block_number | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing that the tool is 'Read-only and keyless,' that it 'Returns live values only,' and that the result is a single object rather than a list. This adds meaningful behavioral context that the annotations alone do not provide, and it does not contradict any annotation.
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 information-dense and front-loaded: purpose comes first, followed by usage context, alternatives, then parameters. Despite length, every sentence earns its place by adding either scoping, routing, or parameter clarification that the schema and annotations do not already cover.
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 fully covers what an agent needs: what the tool returns, when to use it, which siblings to use instead, the read-only/keyless behavior, and the key parameter semantics including the inversed flag. Since an output schema exists, the description does not need to explain return fields in more detail.
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% for all parameters, so the baseline is 3. The description adds value by clarifying the pool_address format with a concrete example and explaining that inversed 'flips the token price ratio to token1/token0,' which is more semantically informative than the schema's 'whether to invert the price ratio'.
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 states a specific verb and resource: 'Get the full current snapshot for one pool by address,' and enumerates exactly what the snapshot contains (tokens, price, liquidity/TVL, 24h volume, transaction counts). It also explicitly says the result is a 'single pool object (not a list),' which clearly distinguishes it from any list-returning sibling.
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 guidance: after search or getNetworkPools surfaces a pool, or for questions like 'price/TVL of this pool?' or 'details for pool 0x...'. It also names concrete alternatives and exclusions: use getPoolOHLCV for historical candles and getPoolTransactions for the raw swap feed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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 |
| Name | Required | Description |
|---|---|---|
| ohlcv | Yes | Open-High-Low-Close-Volume rows ordered by time_open ascending. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description adds context beyond that by stating it is 'Read-only and keyless' and by disclosing constraints such as the 1-year cap after start and the 366-candle maximum. This meaningfully augments the structured 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the resource, output shape, and access traits, and the second sentence gives parameter essentials and usage guidance. Every sentence adds value, and the param summary is dense without being verbose.
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 8-parameter complexity, the description covers purpose, input semantics, constraints, access traits, and sibling differentiation, while the output schema covers return-value details. The only minor omission is the required rationale parameter, but the schema documents it thoroughly, so the definition is complete for correct 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 description coverage is 100%, so the input schema fully documents all 8 parameters, including rationale which the description omits from its param summary. The description does add useful shorthand—start format options, interval enum, end cap, defaults, and max limit—but the schema already carries most of the semantic weight, so a 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 uses a specific verb-resource pair ('Get historical OHLCV candles') and defines the exact scope: one pool over a time range, returned as a time-series array. It also distinguishes itself from getPoolDetails by noting the single-current-price case, so an agent can clearly select this tool over its siblings.
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 lists use cases ('price history of this pair', 'hourly chart for the last week', 'candles since Jan 1', backtesting) and names the alternative for a different need ('for the single current price use getPoolDetails instead'). This gives an agent clear, actionable selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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 |
| Name | Required | Description |
|---|---|---|
| page_info | Yes | |
| transactions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description adds meaningful behavioral context: keyless access, newest-first ordering, response placement under 'transactions', pagination mechanics (page or cursor), and the 7-day window cap. 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 information-dense but well organized: core behavior first, disambiguation second, use cases third, and a compact parameter summary. Every sentence earns its place without unnecessary padding.
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 8 parameters, rich annotations, full schema coverage, and an output schema present, the description still adds essential usage context: pagination trade-offs, the capped date range, and sibling tool differentiation. Nothing critical is missing for correct 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 baseline is 3. The description enhances semantics by grouping page and cursor as alternative pagination methods, explaining the response field 'transactions', and clarifying the from/to time-range semantics in compact form beyond individual schema 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 states a specific verb and resource: get one pool's recent individual swap transactions, newest first. It clearly distinguishes itself from getPoolOHLCV (aggregated candles) and getPoolDetails (summary snapshot), so an agent can select it correctly among siblings.
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 guidance with concrete examples ('recent trades on this pool', 'who swapped in the last hour', 'raw transaction feed') and names alternative tools to avoid. It also clarifies that this tool returns per-trade records, not candles or summary snapshots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. |
| 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. |
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.
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.
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.
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.
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.
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.
Get 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) |
| Name | Required | Description |
|---|---|---|
| id | No | |
| name | No | |
| chain | No | |
| symbol | No | |
| summary | No | |
| website | No | |
| added_at | No | |
| decimals | No | |
| has_image | No | |
| description | No | |
| price_stats | No | |
| total_supply | No | Raw on-chain total supply. Big numbers may overflow JS Number; handle as string for tokens with 18+ decimals. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds beyond these flags by stating the call is keyless, returns a single token object, and includes multi-timeframe metrics plus metadata. This gives the agent practical behavioral context such as no authentication and expected return shape 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?
Every sentence serves a distinct purpose: state the operation, confirm read-only/keyless, provide example queries, route to alternatives, and summarize parameters. It is front-loaded with the core purpose and contains no filler, tautology, or redundant exposition.
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 a full output schema, high schema coverage, and rich annotations, the description provides everything needed to select and invoke the tool correctly. It handles the ambiguous symbol-only case, names related sibling tools, and confirms behavioral expectations. No critical information is missing.
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?
The input schema covers all three required parameters with descriptions, so the baseline is 3. The description adds marginal extra meaning like 'slug' for network and an example token address, but mostly restates what is already in the schema. It does not significantly deepen parameter 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 opens with a specific verb and resource: 'Get one token's data and metadata by contract address on one network.' It lists concrete contents (price/volume metrics, name, website, Twitter, Telegram links) and explicitly distinguishes itself from siblings like getTokenMultiPrices and getTokenPools. An agent can clearly tell what this tool does and does not do.
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 example user intents ('price and volume for 0x... on Base', 'tell me about this token'), instructs to call search first when only a symbol is known, and names alternatives for bulk prices (getTokenMultiPrices) and pools (getTokenPools). This is comprehensive when/when-not guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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. |
| Name | Required | Description |
|---|---|---|
| prices | Yes | USD prices for the requested tokens, in input order. |
| missing_tokens | No | Input tokens that upstream could not price (invalid address, no liquidity, unknown contract). Empty array when all input tokens were resolved. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-destructive, so the description focuses on extra behavior: it is keyless, and tokens that fail to price are returned in missing_tokens instead of being silently dropped, with a warning to check that list. These details materially affect how an agent should interpret results and are not available from annotations alone.
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 every sentence earns its place: purpose, result shape, safety, partial-failure caveat, use cases, sibling alternative, and parameter constraints. It front-loads the core operation before context, so an agent gets the essential decision information first.
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 batched read tool with a full output schema and safety annotations, this description covers the non-obvious failure mode, the intended use cases, the alternative tool, and cross-parameter constraints. There is no critical gap left to guesswork.
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 carries the baseline meaning. The description adds value by emphasizing that network is the slug, all tokens must share it, and tokens are contract addresses, and it restates the 1-to-10 array bound in prose. The required rationale parameter is left to the schema, which is acceptable given its complete description there.
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 first clause names a specific operation ('Get current USD prices'), the exact resource scope ('up to 10 tokens on the same network'), and the call style (one batched call). It also differentiates itself from the close sibling getTokenDetails by stating that getTokenDetails is for one token with metadata and multi-timframe stats.
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 gives explicit matching use cases ('prices for these tokens', 'compare the price of X, Y and Z', portfolio/dashboard snapshot) and names the alternative for single-token enrichment (getTokenDetails). This lets an agent route between siblings without inferring intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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. |
| Name | Required | Description |
|---|---|---|
| query | No | Echo of the resolved query and filters the API applied. |
| results | Yes | |
| next_cursor | No | Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page. |
| has_next_page | No | True if more results are available; fetch them by passing next_cursor as `cursor`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, and non-destructive hints. The description adds useful behavioral context beyond those hints: keyless access, network-scoped behavior, unknown addresses returning empty results rather than errors, and unsupported parameters causing errors. This materially helps the agent predict outcomes.
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 front-loads the core purpose, then gives examples, behavior caveats, and a compact parameter summary. Each sentence carries useful information, and the parameter overview is a helpful condensation rather than redundant padding.
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 13 parameters and rich schema, the description covers the essential runtime facts: pagination shape, network scoping, unknown-address behavior, aliases, defaults, and unsupported parameters. The output schema handles detailed return-value documentation, so nothing critical is missing for correct 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 baseline is 3. The description adds value by summarizing required parameters, defaults, aliases, cursor pagination, and which removed aliases will error. It does not repeat every enum or schema detail, but the prose gives a quick mental model that complements 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 states a specific verb and resource: 'Get the liquidity pools that contain a specific token on one network'. It also names the response shape ('results', 'has_next_page', 'next_cursor') and gives concrete natural-language queries ('which pools hold WETH on ethereum?'). This clearly distinguishes the tool from token-price tools and network-discovery tools.
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, tells the agent to run search first if the network is uncertain, explains the empty-result behavior for unknown addresses, and directs price lookups to getTokenDetails. This is actionable selection guidance beyond a bare capability statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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. |
| Name | Required | Description |
|---|---|---|
| query | No | Echo of the resolved query and filters the API applied. |
| results | Yes | |
| next_cursor | No | Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page. |
| has_next_page | No | True if more results are available; fetch them by passing next_cursor as `cursor`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds useful context: the tool is keyless, pagination uses next_cursor, and ranking by raw price silently falls back to volume. This goes beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that covers purpose, use cases, an alternative, return shape, pagination, defaults, aliases, and a behavioral fallback quirk. It is front-loaded and every sentence adds operational 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?
The output schema exists, so detailed return-value documentation is not needed. The description covers usage scenarios, routing to the alternative, pagination, sorting behavior, defaults, and authentication state. Paramater-level rules like rationale are reasonably left to the schema.
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 input schema already documents all parameters and their defaults. The description mostly restates schema information, adding only minor extra value such as noting that network is a slug. With high schema coverage, the baseline score of 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 opens with a specific verb and object: 'Get the top tokens on one network ranked by volume, liquidity, transactions, FDV, or 24h price change.' It also names the closest alternative, filterNetworkTokens, so an agent can distinguish this tool from its siblings 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete example queries ('top gainers on Solana', 'highest-volume tokens on Base') and explicitly says when to use filterNetworkTokens instead: 'For arbitrary numeric filters or a time window.' This is strong positive and negative routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 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. |
| Name | Required | Description |
|---|---|---|
| dexes | Yes | |
| pools | Yes | |
| tokens | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond that: it is keyless, returns three arrays, and 'No matches returns empty arrays, not an error.' These details help an agent predict behavior without needing to call the tool.
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 and flows logically into usage, behavior, and parameters. It is slightly longer than necessary because the inline 'Params' section partly repeats schema information, but that repetition also adds examples and client-side behavior, so most content earns its place.
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 is nearly complete: it covers cross-network scope, return shape, no-match behavior, keyless access, and routing to sibling tools. The main gap is that the inline parameter list omits the required 'rationale' parameter, but the input schema describes it thoroughly, so an agent using the full tool definition should still invoke 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 the baseline is 3. The description adds extra meaning by providing concrete examples for query and explaining that limit is applied client-side per category. However, the inline params recap omits the required rationale parameter, though the schema fully documents 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?
The description states a specific verb and resource: 'Search across ALL networks at once for tokens, pools, and DEXes.' It names the exact output shape (three arrays) and distinguishes itself from network-scoped siblings, so an agent can clearly understand what this tool does and how it differs.
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 says this is 'the cross-chain entry point when you do not yet know which network something lives on' and instructs switching to 'network-scoped tools' once a network slug is known. It also gives concrete example queries, making the intended usage unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report 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. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | True if the feedback row was persisted. |
| message | Yes | |
| severity | No | |
| tracking_id | No | Stable id agents can reference in follow-up submissions; null if persistence failed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide broad hints (readOnlyHint false, destructiveHint false, etc.), so the description carries the behavioral burden. It discloses that submissions are read, that partial feedback is valued, that there is no rationale field, and that long inputs are validation-rejected at the MCP layer—all useful behavioral context. Nothing in the description contradicts 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 front-loaded with purpose and follows with concrete usage triggers and a low-friction tip; every sentence serves a role. Minor redundancy exists between 'stuck, returned something unexpected, lacked data' and 'dead end, response shape surprised, coverage was missing,' but overall it is appropriately sized and scannable.
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 feedback submission tool, the description covers purpose, when to use it, what behavior to expect, and guidance on structuring feedback. The output schema exists, and the input schema fully documents parameters, so no critical information for correctly invoking the tool is missing.
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 fully documents all six parameters and their constraints. The description reinforces the goal/expected/observed trio and mentions length caps, but this adds only marginal framing rather than genuinely new parameter meaning. Baseline 3 is appropriate given the complete schema 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?
The description uses a specific verb and resource ('Report a problem back to the DexPaprika team') and clearly enumerates the situations that warrant submission. It is unmistakably distinct from the data-retrieval sibling tools, none of which handle user feedback.
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 says 'Use whenever you hit a dead end, a response shape surprised you, or coverage was missing,' giving concrete trigger conditions. It also clarifies that partial feedback is acceptable and directs agents to provide goal, expected, and observed, which functions as usage guidance. No alternative feedback tool exists among siblings, so exclusion statements are unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
filterNetworkTokens3 fields changedInput schema / properties / price_change_percentage_24h_maxAdded value: +{
+ "description": "OPTIONAL: Maximum 24h price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_24h_minAdded value: +{
+ "description": "OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds tokens down at least 20%. This is the only price-change window tokens carry; for 6h, 1h or 5m use getNetworkPoolsFilter.",
+ "type": "number"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "has_next_page": {
+ "description": "True if more results are available; fetch them by passing next_cursor as `cursor`.",
+ "type": "boolean"
+ },
+ "next_cursor": {
+ "description": "Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "query": {
+ "additionalProperties": {},
+ "description": "Echo of the resolved query and filters the API applied.",
+ "type": "object"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": "string"
+ },
+ "chain": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "symbol": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}getCapabilities1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "agent_skills": {
+ "type": "string"
+ },
+ "common_pitfalls": {
+ "description": "Known edge cases agents should be aware of.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "documentation": {
+ "type": "string"
+ },
+ "network_synonyms": {
+ "additionalProperties": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": "Canonical network id -> common alternates an agent might try.",
+ "type": "object"
+ },
+ "server": {
+ "additionalProperties": true,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "version"
+ ],
+ "type": "object"
+ },
+ "stats": {
+ "additionalProperties": true,
+ "properties": {
+ "console_url": {
+ "type": "string"
+ },
+ "docs_url": {
+ "type": "string"
+ },
+ "free_key_credits_per_month": {
+ "type": "number"
+ },
+ "free_key_requests_per_minute": {
+ "type": "number"
+ },
+ "free_tier": {
+ "type": "boolean"
+ },
+ "free_tier_credits_per_month": {
+ "type": "number"
+ },
+ "free_tier_max_data_delay_seconds": {
+ "type": "number"
+ },
+ "free_tier_requests_per_minute": {
+ "type": "number"
+ },
+ "key_required_to_start": {
+ "type": "boolean"
+ },
+ "networks": {
+ "type": "number"
+ },
+ "pools_approx": {
+ "type": "number"
+ },
+ "pricing_url": {
+ "type": "string"
+ },
+ "tokens_approx": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "networks",
+ "tokens_approx",
+ "pools_approx",
+ "free_tier",
+ "key_required_to_start"
+ ],
+ "type": "object"
+ },
+ "workflows": {
+ "additionalProperties": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": "Named tool sequences for common agent tasks.",
+ "type": "object"
+ }
+ },
+ "required": [
+ "server",
+ "stats",
+ "network_synonyms",
+ "workflows",
+ "common_pitfalls",
+ "documentation",
+ "agent_skills"
+ ],
+ "type": "object"
+}getDexPools3 fields changedInput schema / properties / order_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "has_next_page": {
+ "description": "True if more results are available; fetch them by passing next_cursor as `cursor`.",
+ "type": "boolean"
+ },
+ "next_cursor": {
+ "description": "Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "query": {
+ "additionalProperties": {},
+ "description": "Echo of the resolved query and filters the API applied.",
+ "type": "object"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.",
+ "type": "string"
+ },
+ "created_at": {
+ "description": "ISO 8601 pool-creation timestamp.",
+ "type": "string"
+ },
+ "created_at_block_number": {
+ "type": "number"
+ },
+ "dex_id": {
+ "type": "string"
+ },
+ "dex_name": {
+ "type": "string"
+ },
+ "fee": {
+ "description": "Pool fee (units depend on DEX; null for some DEXes).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Pool contract address.",
+ "type": "string"
+ },
+ "last_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "last_price_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tokens": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": "string"
+ },
+ "chain": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "symbol": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}getNetworkDexes1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "dexes": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "type": "string"
+ },
+ "dex_id": {
+ "type": "string"
+ },
+ "dex_name": {
+ "type": "string"
+ },
+ "display_name": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "network_id": {
+ "type": "string"
+ },
+ "pools_count": {
+ "type": "number"
+ },
+ "protocol": {
+ "type": "string"
+ },
+ "txns_24h": {
+ "type": "number"
+ },
+ "volume_usd_24h": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "page_info": {
+ "additionalProperties": true,
+ "properties": {
+ "limit": {
+ "description": "Items per page in the request.",
+ "type": "number"
+ },
+ "page": {
+ "description": "Current page number (1-indexed).",
+ "type": "number"
+ },
+ "total_items": {
+ "description": "Total number of items across all pages.",
+ "type": "number"
+ },
+ "total_pages": {
+ "description": "Total number of pages available.",
+ "type": "number"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "dexes",
+ "page_info"
+ ],
+ "type": "object"
+}getNetworkPools3 fields changedInput schema / properties / order_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "has_next_page": {
+ "description": "True if more results are available; fetch them by passing next_cursor as `cursor`.",
+ "type": "boolean"
+ },
+ "next_cursor": {
+ "description": "Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "query": {
+ "additionalProperties": {},
+ "description": "Echo of the resolved query and filters the API applied.",
+ "type": "object"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.",
+ "type": "string"
+ },
+ "created_at": {
+ "description": "ISO 8601 pool-creation timestamp.",
+ "type": "string"
+ },
+ "created_at_block_number": {
+ "type": "number"
+ },
+ "dex_id": {
+ "type": "string"
+ },
+ "dex_name": {
+ "type": "string"
+ },
+ "fee": {
+ "description": "Pool fee (units depend on DEX; null for some DEXes).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Pool contract address.",
+ "type": "string"
+ },
+ "last_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "last_price_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tokens": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": "string"
+ },
+ "chain": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "symbol": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}getNetworkPoolsFilter11 fields changedInput schema / properties / order_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / price_change_percentage_1h_maxAdded value: +{
+ "description": "OPTIONAL: Maximum 1h price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_1h_minAdded value: +{
+ "description": "OPTIONAL: Minimum 1h price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_24h_maxAdded value: +{
+ "description": "OPTIONAL: Maximum 24h price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_24h_minAdded value: +{
+ "description": "OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds pools down at least 20%.",
+ "type": "number"
+}Input schema / properties / price_change_percentage_5m_maxAdded value: +{
+ "description": "OPTIONAL: Maximum 5m price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_5m_minAdded value: +{
+ "description": "OPTIONAL: Minimum 5m price change, in percent. The shortest window we carry, so it is the one to reach for on 'what is moving right now'.",
+ "type": "number"
+}Input schema / properties / price_change_percentage_6h_maxAdded value: +{
+ "description": "OPTIONAL: Maximum 6h price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_6h_minAdded value: +{
+ "description": "OPTIONAL: Minimum 6h price change, in percent",
+ "type": "number"
+}Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "has_next_page": {
+ "description": "True if more results are available; fetch them by passing next_cursor as `cursor`.",
+ "type": "boolean"
+ },
+ "next_cursor": {
+ "description": "Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "query": {
+ "additionalProperties": {},
+ "description": "Echo of the resolved query and filters the API applied.",
+ "type": "object"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.",
+ "type": "string"
+ },
+ "created_at": {
+ "description": "ISO 8601 pool-creation timestamp.",
+ "type": "string"
+ },
+ "created_at_block_number": {
+ "type": "number"
+ },
+ "dex_id": {
+ "type": "string"
+ },
+ "dex_name": {
+ "type": "string"
+ },
+ "fee": {
+ "description": "Pool fee (units depend on DEX; null for some DEXes).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Pool contract address.",
+ "type": "string"
+ },
+ "last_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "last_price_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tokens": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": "string"
+ },
+ "chain": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "symbol": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}getNetworks1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "networks": {
+ "description": "All supported blockchain networks with current 24h volume + indexing stats.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "display_name": {
+ "description": "Human-readable network name (e.g. 'Ethereum').",
+ "type": "string"
+ },
+ "id": {
+ "description": "Network slug for use in other endpoints (e.g. 'ethereum').",
+ "type": "string"
+ },
+ "pools_count": {
+ "description": "Number of indexed pools on this network.",
+ "type": "number"
+ },
+ "txns_24h": {
+ "description": "Total transactions in the last 24h on this network.",
+ "type": "number"
+ },
+ "volume_usd_24h": {
+ "description": "Total 24h trading volume across all pools on this network, USD.",
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "networks"
+ ],
+ "type": "object"
+}getPoolDetails1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "type": "string"
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "created_at_block_number": {
+ "type": "number"
+ },
+ "dex_id": {
+ "type": "string"
+ },
+ "dex_name": {
+ "type": "string"
+ },
+ "factory_id": {
+ "type": "string"
+ },
+ "fee": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "last_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "last_price_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price_stats": {},
+ "price_time": {
+ "type": "string"
+ },
+ "token_reserves": {
+ "items": {},
+ "type": "array"
+ },
+ "tokens": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": "string"
+ },
+ "chain": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "symbol": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}getPoolOHLCV1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "ohlcv": {
+ "description": "Open-High-Low-Close-Volume rows ordered by time_open ascending.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "close": {
+ "type": "number"
+ },
+ "high": {
+ "type": "number"
+ },
+ "low": {
+ "type": "number"
+ },
+ "open": {
+ "type": "number"
+ },
+ "time_close": {
+ "description": "ISO 8601 timestamp of bucket close (inclusive at 23:59:59 for 24h).",
+ "type": "string"
+ },
+ "time_open": {
+ "description": "ISO 8601 timestamp of bucket open.",
+ "type": "string"
+ },
+ "volume": {
+ "description": "Trade volume in the bucket, in pair-quote units (or USD where applicable).",
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "ohlcv"
+ ],
+ "type": "object"
+}getPoolTransactions2 fields changedInput schema / properties / from / descriptionPrevious value: -"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."New value: +"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."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "page_info": {
+ "additionalProperties": true,
+ "properties": {
+ "limit": {
+ "description": "Items per page in the request.",
+ "type": "number"
+ },
+ "page": {
+ "description": "Current page number (1-indexed).",
+ "type": "number"
+ },
+ "total_items": {
+ "description": "Total number of items across all pages.",
+ "type": "number"
+ },
+ "total_pages": {
+ "description": "Total number of pages available.",
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "transactions": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "amount_usd": {
+ "type": "number"
+ },
+ "block_number": {
+ "type": "number"
+ },
+ "block_timestamp": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pool_id": {
+ "type": "string"
+ },
+ "token0": {},
+ "token1": {}
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "transactions",
+ "page_info"
+ ],
+ "type": "object"
+}getStats1 field 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"
+}getTokenDetails1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "type": "string"
+ },
+ "chain": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "has_image": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "price_stats": {},
+ "summary": {},
+ "symbol": {
+ "type": "string"
+ },
+ "total_supply": {
+ "description": "Raw on-chain total supply. Big numbers may overflow JS Number; handle as string for tokens with 18+ decimals.",
+ "type": [
+ "number",
+ "string"
+ ]
+ },
+ "website": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}getTokenMultiPrices1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "missing_tokens": {
+ "description": "Input tokens that upstream could not price (invalid address, no liquidity, unknown contract). Empty array when all input tokens were resolved.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "prices": {
+ "description": "USD prices for the requested tokens, in input order.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "type": "string"
+ },
+ "id": {
+ "description": "Token contract address.",
+ "type": "string"
+ },
+ "price_usd": {
+ "description": "Current USD price; null if not available.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "prices"
+ ],
+ "type": "object"
+}getTokenPools3 fields changedInput schema / properties / order_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "has_next_page": {
+ "description": "True if more results are available; fetch them by passing next_cursor as `cursor`.",
+ "type": "boolean"
+ },
+ "next_cursor": {
+ "description": "Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "query": {
+ "additionalProperties": {},
+ "description": "Echo of the resolved query and filters the API applied.",
+ "type": "object"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.",
+ "type": "string"
+ },
+ "created_at": {
+ "description": "ISO 8601 pool-creation timestamp.",
+ "type": "string"
+ },
+ "created_at_block_number": {
+ "type": "number"
+ },
+ "dex_id": {
+ "type": "string"
+ },
+ "dex_name": {
+ "type": "string"
+ },
+ "fee": {
+ "description": "Pool fee (units depend on DEX; null for some DEXes).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Pool contract address.",
+ "type": "string"
+ },
+ "last_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "last_price_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tokens": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": "string"
+ },
+ "chain": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "symbol": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}getTopTokens1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "has_next_page": {
+ "description": "True if more results are available; fetch them by passing next_cursor as `cursor`.",
+ "type": "boolean"
+ },
+ "next_cursor": {
+ "description": "Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "query": {
+ "additionalProperties": {},
+ "description": "Echo of the resolved query and filters the API applied.",
+ "type": "object"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": "string"
+ },
+ "chain": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "symbol": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}search1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "dexes": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "type": "string"
+ },
+ "dex_id": {
+ "type": "string"
+ },
+ "dex_name": {
+ "type": "string"
+ },
+ "display_name": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "network_id": {
+ "type": "string"
+ },
+ "pools_count": {
+ "type": "number"
+ },
+ "protocol": {
+ "type": "string"
+ },
+ "txns_24h": {
+ "type": "number"
+ },
+ "volume_usd_24h": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "pools": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.",
+ "type": "string"
+ },
+ "created_at": {
+ "description": "ISO 8601 pool-creation timestamp.",
+ "type": "string"
+ },
+ "created_at_block_number": {
+ "type": "number"
+ },
+ "dex_id": {
+ "type": "string"
+ },
+ "dex_name": {
+ "type": "string"
+ },
+ "fee": {
+ "description": "Pool fee (units depend on DEX; null for some DEXes).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Pool contract address.",
+ "type": "string"
+ },
+ "last_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "last_price_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tokens": {
+ "items": {
+ "$ref": "#/properties/tokens/items"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "tokens": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": "string"
+ },
+ "chain": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "symbol": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "tokens",
+ "pools",
+ "dexes"
+ ],
+ "type": "object"
+}submitFeedback1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "ok": {
+ "description": "True if the feedback row was persisted.",
+ "type": "boolean"
+ },
+ "severity": {
+ "enum": [
+ "blocker",
+ "major",
+ "minor",
+ "nit"
+ ],
+ "type": "string"
+ },
+ "tracking_id": {
+ "description": "Stable id agents can reference in follow-up submissions; null if persistence failed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ok",
+ "message"
+ ],
+ "type": "object"
+}filterNetworkTokens2 fields changedInput schema / properties / price_change_percentage_24h_maxRemoved value: -{
- "description": "OPTIONAL: Maximum 24h price change, in percent",
- "type": "number"
-}Input schema / properties / price_change_percentage_24h_minRemoved value: -{
- "description": "OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds tokens down at least 20%. This is the only price-change window tokens carry; for 6h, 1h or 5m use getNetworkPoolsFilter.",
- "type": "number"
-}getDexPools2 fields changedInput schema / properties / order_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "price_change_percentage_6h",
- "price_change_percentage_1h",
- "price_change_percentage_5m",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "price_change_percentage_6h",
- "price_change_percentage_1h",
- "price_change_percentage_5m",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]getNetworkPools2 fields changedInput schema / properties / order_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "price_change_percentage_6h",
- "price_change_percentage_1h",
- "price_change_percentage_5m",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "price_change_percentage_6h",
- "price_change_percentage_1h",
- "price_change_percentage_5m",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]getNetworkPoolsFilter10 fields changedInput schema / properties / order_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "price_change_percentage_6h",
- "price_change_percentage_1h",
- "price_change_percentage_5m",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / price_change_percentage_1h_maxRemoved value: -{
- "description": "OPTIONAL: Maximum 1h price change, in percent",
- "type": "number"
-}Input schema / properties / price_change_percentage_1h_minRemoved value: -{
- "description": "OPTIONAL: Minimum 1h price change, in percent",
- "type": "number"
-}Input schema / properties / price_change_percentage_24h_maxRemoved value: -{
- "description": "OPTIONAL: Maximum 24h price change, in percent",
- "type": "number"
-}Input schema / properties / price_change_percentage_24h_minRemoved value: -{
- "description": "OPTIONAL: Minimum 24h price change, in percent. Negative values are allowed, so -20 finds pools down at least 20%.",
- "type": "number"
-}Input schema / properties / price_change_percentage_5m_maxRemoved value: -{
- "description": "OPTIONAL: Maximum 5m price change, in percent",
- "type": "number"
-}Input schema / properties / price_change_percentage_5m_minRemoved value: -{
- "description": "OPTIONAL: Minimum 5m price change, in percent. The shortest window we carry, so it is the one to reach for on 'what is moving right now'.",
- "type": "number"
-}Input schema / properties / price_change_percentage_6h_maxRemoved value: -{
- "description": "OPTIONAL: Maximum 6h price change, in percent",
- "type": "number"
-}Input schema / properties / price_change_percentage_6h_minRemoved value: -{
- "description": "OPTIONAL: Minimum 6h price change, in percent",
- "type": "number"
-}Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "price_change_percentage_6h",
- "price_change_percentage_1h",
- "price_change_percentage_5m",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]getTokenPools2 fields changedInput schema / properties / order_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "price_change_percentage_6h",
- "price_change_percentage_1h",
- "price_change_percentage_5m",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "price_change_percentage_6h",
- "price_change_percentage_1h",
- "price_change_percentage_5m",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]filterNetworkTokens2 fields changedInput schema / properties / price_change_percentage_24h_maxAdded value: +{
+ "description": "OPTIONAL: Maximum 24h price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_24h_minAdded value: +{
+ "description": "OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds tokens down at least 20%. This is the only price-change window tokens carry; for 6h, 1h or 5m use getNetworkPoolsFilter.",
+ "type": "number"
+}getDexPools2 fields changedInput schema / properties / order_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]getNetworkPools2 fields changedInput schema / properties / order_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]getNetworkPoolsFilter10 fields changedInput schema / properties / order_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / price_change_percentage_1h_maxAdded value: +{
+ "description": "OPTIONAL: Maximum 1h price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_1h_minAdded value: +{
+ "description": "OPTIONAL: Minimum 1h price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_24h_maxAdded value: +{
+ "description": "OPTIONAL: Maximum 24h price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_24h_minAdded value: +{
+ "description": "OPTIONAL: Minimum 24h price change, in percent. Negative values are allowed, so -20 finds pools down at least 20%.",
+ "type": "number"
+}Input schema / properties / price_change_percentage_5m_maxAdded value: +{
+ "description": "OPTIONAL: Maximum 5m price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_5m_minAdded value: +{
+ "description": "OPTIONAL: Minimum 5m price change, in percent. The shortest window we carry, so it is the one to reach for on 'what is moving right now'.",
+ "type": "number"
+}Input schema / properties / price_change_percentage_6h_maxAdded value: +{
+ "description": "OPTIONAL: Maximum 6h price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_6h_minAdded value: +{
+ "description": "OPTIONAL: Minimum 6h price change, in percent",
+ "type": "number"
+}Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]getTokenPools2 fields changedInput schema / properties / order_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd_24h",
- "volume_usd_7d",
- "volume_usd_30d",
- "liquidity_usd",
- "txns_24h",
- "created_at",
- "price_usd",
- "price_change_percentage_24h",
- "volume_usd",
- "transactions",
- "last_price_change_usd_24h",
- "volume_24h",
- "volume_7d",
- "volume_30d",
- "liquidity"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "price_change_percentage_6h",
+ "price_change_percentage_1h",
+ "price_change_percentage_5m",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]getDexPools7 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "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.",
+ "type": "string"
+}Input schema / properties / dex / descriptionPrevious value: -"REQUIRED: DEX identifier from getNetworkDexes (e.g., 'uniswap_v3')"New value: +"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."Input schema / properties / order_by / enumPrevious value: -[
- "volume_usd",
- "price_usd",
- "transactions",
- "last_price_change_usd_24h",
- "created_at"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]Input schema / properties / page / defaultRemoved value: -1Input schema / properties / page / descriptionPrevious value: -"OPTIONAL: Page number, 1-indexed. Server accepts page=0 (treated as page=1) for backward compatibility."New value: +"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."Input schema / properties / sort_by / descriptionPrevious value: -"OPTIONAL: Sort field. Canonical parameter name. Defaults to 'volume_usd' if neither sort_by nor order_by is provided. The REST API calls this parameter order_by."New value: +"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."Input schema / properties / sort_by / enumPrevious value: -[
- "volume_usd",
- "price_usd",
- "transactions",
- "last_price_change_usd_24h",
- "created_at"
-]New value: +[
+ "volume_usd_24h",
+ "volume_usd_7d",
+ "volume_usd_30d",
+ "liquidity_usd",
+ "txns_24h",
+ "created_at",
+ "price_usd",
+ "price_change_percentage_24h",
+ "volume_usd",
+ "transactions",
+ "last_price_change_usd_24h",
+ "volume_24h",
+ "volume_7d",
+ "volume_30d",
+ "liquidity"
+]filterNetworkTokens4 fields changedInput schema / properties / order_by / descriptionPrevious value: -"DEPRECATED alias for sort_by. Both accepted; prefer sort_by going forward."New value: +"OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly."Input schema / properties / sort / descriptionPrevious value: -"DEPRECATED alias for sort_dir. Both accepted; prefer sort_dir going forward."New value: +"OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly."Input schema / properties / sort_by / descriptionPrevious value: -"OPTIONAL: Sort field. Defaults to 'volume_usd_24h'. Prefer the canonical names; short legacy names are still accepted."New value: +"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."Input schema / properties / sort_dir / descriptionPrevious value: -"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided."New value: +"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort."getDexPools4 fields changedInput schema / properties / order_by / descriptionPrevious value: -"DEPRECATED alias for sort_by. Both accepted; prefer sort_by going forward."New value: +"OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly."Input schema / properties / sort / descriptionPrevious value: -"DEPRECATED alias for sort_dir. Both accepted; prefer sort_dir going forward."New value: +"OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly."Input schema / properties / sort_by / descriptionPrevious value: -"OPTIONAL: Sort field. Canonical parameter name. Defaults to 'volume_usd' if neither sort_by nor order_by is provided."New value: +"OPTIONAL: Sort field. Canonical parameter name. Defaults to 'volume_usd' if neither sort_by nor order_by is provided. The REST API calls this parameter order_by."Input schema / properties / sort_dir / descriptionPrevious value: -"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided."New value: +"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort."getNetworkDexes4 fields changedInput schema / properties / order_by / descriptionPrevious value: -"DEPRECATED alias for sort_by. Both accepted; prefer sort_by going forward."New value: +"OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly."Input schema / properties / sort / descriptionPrevious value: -"DEPRECATED alias for sort_dir. Both accepted; prefer sort_dir going forward."New value: +"OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly."Input schema / properties / sort_by / descriptionPrevious value: -"OPTIONAL: Sort field. Canonical parameter name; older tools used order_by."New value: +"OPTIONAL: Sort field. Canonical parameter name; older tools used order_by. The REST API calls this parameter order_by."Input schema / properties / sort_dir / descriptionPrevious value: -"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided."New value: +"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort."getNetworkPools4 fields changedInput schema / properties / order_by / descriptionPrevious value: -"DEPRECATED alias for sort_by. Both accepted; prefer sort_by going forward."New value: +"OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly."Input schema / properties / sort / descriptionPrevious value: -"DEPRECATED alias for sort_dir. Both accepted; prefer sort_dir going forward."New value: +"OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly."Input schema / properties / sort_by / descriptionPrevious value: -"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."New value: +"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."Input schema / properties / sort_dir / descriptionPrevious value: -"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided."New value: +"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort."getNetworkPoolsFilter4 fields changedInput schema / properties / order_by / descriptionPrevious value: -"DEPRECATED alias for sort_by. Both accepted; prefer sort_by going forward."New value: +"OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly."Input schema / properties / sort / descriptionPrevious value: -"DEPRECATED alias for sort_dir. Both accepted; prefer sort_dir going forward."New value: +"OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly."Input schema / properties / sort_by / descriptionPrevious value: -"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."New value: +"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."Input schema / properties / sort_dir / descriptionPrevious value: -"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided."New value: +"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort."getTokenPools4 fields changedInput schema / properties / order_by / descriptionPrevious value: -"DEPRECATED alias for sort_by. Both accepted; prefer sort_by going forward."New value: +"OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly."Input schema / properties / sort / descriptionPrevious value: -"DEPRECATED alias for sort_dir. Both accepted; prefer sort_dir going forward."New value: +"OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly."Input schema / properties / sort_by / descriptionPrevious value: -"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."New value: +"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."Input schema / properties / sort_dir / descriptionPrevious value: -"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided."New value: +"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort."getTopTokens4 fields changedInput schema / properties / order_by / descriptionPrevious value: -"DEPRECATED alias for sort_by. Both accepted; prefer sort_by going forward."New value: +"OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly."Input schema / properties / sort / descriptionPrevious value: -"DEPRECATED alias for sort_dir. Both accepted; prefer sort_dir going forward."New value: +"OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly."Input schema / properties / sort_by / descriptionPrevious value: -"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."New value: +"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."Input schema / properties / sort_dir / descriptionPrevious value: -"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided."New value: +"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort."filterNetworkTokensgetCapabilitiesgetDexPoolsgetNetworkDexesgetNetworkPoolsgetNetworkPoolsFiltergetNetworksgetPoolDetailsgetPoolOHLCVgetPoolTransactionsgetStatsgetTokenDetailsgetTokenMultiPricesgetTokenPoolsgetTopTokenssearchsubmitFeedbackClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action: list vs filtered variants of tokens/pools are explicitly cross-referenced, and single-pool, OHLCV, and transaction tools are clearly separated. Descriptions repeatedly tell the agent which tool to prefer for numeric filters, rankings, or cross-chain search, so ambiguity is minimal.
Tool names are consistently camelCase and mostly follow a get-resource pattern, making them predictable. Minor deviations exist: 'filterNetworkTokens' places the filter first while 'getNetworkPoolsFilter' places it last, and 'search' plus 'submitFeedback' break the get-prefix convention, but the overall pattern is still readable.
Seventeen tools is slightly above the ideal 3-15 range, but the server covers a broad read-only DEX analytics domain spanning networks, DEXes, pools, tokens, transactions, and metadata. A few near-analogous variants like top-tokens vs filtered-tokens and network-pools vs filtered-pools could theoretically be consolidated, yet each earns a place.
The tool surface covers the core domain well: network discovery, DEX listing, pool discovery/detail/history/transactions, token search/detail/prices/pools, stats, and capabilities. Minor gaps exist, such as no direct token-level OHLCV endpoint, no cross-network token-pool tool without search workarounds, and no single-DEX detail endpoint, but agents can work around these using existing tools.