Real-time DEX and on-chain data across 36 blockchains: liquidity pools, token prices, OHLCV, transactions, and cross-chain search. 17 keyless tools.
Scored across 20 tools
Tools are clearly partitioned by resource (network, DEX, pool, token) and action (details, filtering, OHLCV, indicators, transactions). Overlaps such as getNetworkPools vs getNetworkPoolsFilter and getTopTokens vs filterNetworkTokens are explicitly disambiguated by guidance about numeric constraints and time windows. Pool-level versus token-level OHLCV/indicator tools are also clearly scoped.
All tool names use camelCase consistently and follow a verb-first pattern: get*, filter*, search, submitFeedback. Resource and action qualifiers are predictable, e.g. getPoolOHLCV, getTokenOHLCV, getNetworkPoolsFilter. There is no mixing of naming conventions.
Twenty tools is on the high side but is justified by the breadth of the read-only DeFi data surface: discovery, network/DEX/pool/token metadata, OHLCV, indicators, transactions, and feedback. The ranked-versus-filtered listing pairs are purposeful rather than accidental. It is slightly above the ideal 3-15 range for a single server.
The surface covers discovery, network/DEX/pool/token metadata, current prices, OHLCV candles, technical indicators, raw transactions, cross-chain search, platform stats, and feedback. Since this is a read-only market-data API, traditional CRUD gaps do not apply. Paid-key limitations are documented and fallback paths are suggested, leaving no obvious core dead ends.
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 (a relative offset such as '-24h', Unix seconds, RFC3339 or YYYY-MM-DD). 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). Pools and tokens created in the last hour are left out: this server searches like a free key, so a created_after window shorter than an hour comes back empty. A Dev plan or higher on your own key, calling the API directly, sees them as they are indexed.
| 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 at or after this time: a relative offset such as '-24h' or '-7d', Unix seconds, RFC3339 or YYYY-MM-DD | |
| created_before | No | OPTIONAL: Only tokens created at or before this time, same formats as created_after (e.g. '-1h') | |
| 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?
Beyond the annotations it discloses the return envelope (results/has_next_page/next_cursor), that filters are AND-combined, and a non-obvious data gap: tokens and pools created in the last hour are omitted on the free/keyless tier, so sub-hour created_after windows return empty. That is genuinely useful behavioral context that annotations cannot express, though the 'read-only and keyless' clause largely restates readOnlyHint.
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?
Usage guidance and the response envelope are front-loaded, which is good, but the middle enumerates every filter and its default in a form that repeats the schema verbatim, and the closing sentence about the Dev plan/own API key is tangential to calling this tool. Roughly a third of the text could be cut without losing decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 19-parameter read tool with an output schema and full annotation coverage, the description supplies everything an agent still needs: when to pick it over siblings, filter-combination semantics, pagination via cursor, and the recently-created-token blind spot. Return values are correctly left to the output 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 already 100%, so baseline is 3; the description still adds real meaning by declaring the filter set AND-combined, spelling out accepted time formats for created_after/created_before, and noting the sort_by/order_by and sort_dir/sort aliases with their defaults. It does duplicate several schema-documented defaults (limit 50/max 100) rather than adding to them.
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 ('Get tokens on one network matching numeric thresholds') plus the response envelope, and explicitly contrasts with the sibling getTopTokens. An agent can distinguish it from getTopTokens, getNetworkPoolsFilter, and getTokenDetails without opening a 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?
Gives an explicit selection rule ('Choose this over getTopTokens when the user gives numeric constraints or a time window') and three concrete example queries that map user phrasing to this tool. It also names the fallback for other price-change windows (getNetworkPoolsFilter).
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. |
| rate_limits | No | How limits work for hosted tool calls. Not the REST allowances: your own plan does not apply, except to own_key_tools. |
| 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 cover readOnly/idempotent/non-destructive, and the description still adds real context: "keyless" (no auth needed) and the explicit content boundary that it returns onboarding docs, not live market data. It does not mention caching or rate limits, but for a static doc endpoint that is a minor omission.
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?
Front-loads the resource and its contents, then usage timing, then exclusions — a sensible order with no filler sentences. It is on the long side with multiple quoted example phrasings, but each line carries routing or context 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?
With an output schema present, return-value detail is not required, and the description still tells the agent the shape of the content and what it is not. Purpose, timing, auth profile, and sibling alternatives are all covered for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the rationale parameter is fully documented in the schema, including length bounds and PII rules. The description only notes "takes no parameters beyond a short rationale," which correctly signals to the agent that there is nothing substantive to configure.
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 ("Get the static agent onboarding guide for this server") and enumerates its contents: workflows, slug synonyms, call sequences, pitfalls. It also explicitly distinguishes itself from getNetworks and getStats, so an agent can separate it from the ~19 siblings without opening a 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?
Gives explicit timing ("once at the start of a session before your first query") and names the exact user phrasings that should trigger it. It also routes elsewhere for adjacent needs (getNetworks for slug lists, getStats for coverage totals), which is textbook alternative guidance.
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 cover the read-only/idempotent safety profile, but the description adds behavior the annotations cannot express: keyless access, the empty-results[]-instead-of-error trap for wrong dex name form, removal of the old endpoint and the resulting field rename (volume_usd_24h), and the fact that page>=2 errors while pointing at cursor. These are exactly the failure modes an agent would otherwise hit blind.
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, scope and the sibling comparison are correctly front-loaded, but the trailing 'Params: ...' run-on largely duplicates the input schema verbatim, and the dex_name/dex_id warning is repeated almost word-for-word from the schema. Semicolon-chained clauses make it dense; roughly a third of the text is recoverable from structured fields.
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 10-parameter tool with full schema coverage, annotations and an output schema, this is more than sufficient — return shape (results, has_next_page, next_cursor) is mentioned even though the output schema already covers it. Slightly over-complete rather than under-complete, which is a redundancy issue, not a gap.
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 parameter section restates what the schema already documents (limit default/max, cursor=next_cursor, sort_by default and legacy aliases, sort_dir alias sort, page superseded) rather than adding new meaning, so it earns no lift above baseline.
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 (pools belonging to one DEX on one network) and immediately concretizes it with 'all Uniswap v3 pools on ethereum'. It explicitly positions the tool against its sibling getNetworkPools ('Narrower than getNetworkPools (a single exchange, not the whole chain)'), so an agent can separate the two without opening either 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?
Gives explicit invocation scenarios ('show me Raydium pools', 'top pairs on PancakeSwap', 'liquidity on Orca'), names the sibling it is narrower than, and states the prerequisite chain (get the dex id from getNetworkDexes or search first). It also gives a negative rule — do not pass dex_name — with the consequence of getting it wrong.
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 declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds genuinely new context beyond that: 'keyless' auth and the response envelope ('dexes' plus page_info with page and total_pages), which tells the agent pagination exists. It does not discuss rate limits or ordering guarantees, keeping it short of a 5.
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?
Front-loaded with purpose and return shape, then use cases, then scope warning, then params — a sensible ordering. It is a single dense paragraph with some redundancy in restating all parameter defaults, but no sentence is 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?
With an output schema present, the description needn't detail return values, and it still sketches the envelope. Ranges, defaults, alias handling, prerequisites and downstream usage are all covered; only the mandatory rationale convention is left to the server instructions field.
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 nonetheless consolidates the parameters with defaults and ranges (limit default 10 max 100, page 1-indexed, sort_by only 'pool', sort_dir default 'desc') and flags the legacy aliases order_by/sort, which helps an agent avoid the alias trap. The required 'rationale' parameter is not mentioned, which is the only gap.
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?
Names a specific verb and resource ('List the DEXes operating on one network') and immediately grounds it with concrete examples (Uniswap on ethereum, Raydium on solana). It also distinguishes itself from siblings by scoping to a single network and pointing to getDexPools for the follow-on step.
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 usage contexts are given as quoted user questions ('which DEXes are on Base?', 'does Solana have Orca?') plus a stated precondition ('call getNetworks first for the slug') and an explicit downstream consumer (getDexPools). Scope limit is stated as 'single network', which excludes the wrong calls.
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?
The annotations already establish read-only, non-destructive, idempotent, open-world behavior. The description adds useful context beyond annotations by noting the tool is keyless and by explaining the response envelope: results with has_next_page and next_cursor for pagination. It does not cover rate limits or broader operational caveats, so it is strong but not exhaustive.
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 return shape, then usage examples, alternatives, and parameter notes. It is dense and mostly earns its space, though the parameter sentence largely repeats schema content and makes the definition longer than strictly necessary.
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 an 8-parameter, 100%-covered schema with an output schema and rich annotations, the description is complete enough to call the tool correctly. It covers purpose, expected use cases, sibling alternatives, pagination behavior, and key defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter, including defaults, enums, and aliases. The description summarizes the same parameter facts but does not add meaning beyond the schema, 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 states a specific verb and resource: get top liquidity pools across a whole network, ranked by 24h volume by default. It also explicitly distinguishes this as the primary chain-wide pool discovery tool versus getDexPools and getNetworkPoolsFilter, so an agent can identify its role without opening 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?
It gives concrete usage examples such as 'biggest pools on ethereum' and 'top trading pairs on Base', and names alternatives explicitly: use getDexPools to narrow to one exchange and getNetworkPoolsFilter for numeric/time filters. When-to-use and when-to-use-something-else are both clear.
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,48h,6h,1h,5m}_min/max (percent, negatives allowed), created_after/created_before (a relative offset such as '-24h', Unix seconds, RFC3339 or YYYY-MM-DD). 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). Pools and tokens created in the last hour are left out: this server searches like a free key, so a created_after window shorter than an hour comes back empty. A Dev plan or higher on your own key, calling the API directly, sees them as they are indexed.
| 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 at or after this time: a relative offset such as '-24h' or '-7d', Unix seconds, RFC3339 or YYYY-MM-DD | |
| 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 at or before this time, same formats as created_after (e.g. '-1h') | |
| 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%. | |
| price_change_percentage_48h_max | No | OPTIONAL: Maximum 48h price change, in percent | |
| price_change_percentage_48h_min | No | OPTIONAL: Minimum 48h price change, in percent |
| 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/idempotentHint/destructiveHint, yet the description still adds substantive behavior: it is keyless, filters are AND-combined, and — crucially — pools created in the last hour are excluded so a sub-hour created_after window returns empty. That fresh-pool caveat and the Dev-plan workaround are exactly the kind of surprise an agent needs warned about. It does not cover rate limits or result-size behavior beyond the limit/cursor notes, keeping it just short of a 5.
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 and sibling selection are front-loaded, then filtering detail, then caveats — a sensible order. It is dense but largely earns its length; the long enumeration of filter names partially duplicates the schema, which is the only real slack.
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 27-parameter filter tool this covers everything an agent needs: what it returns, how to paginate, when to prefer it, AND-combination of filters, defaults/aliases, and the free-tier indexing gap. With an output schema present, the description is not obligated to explain return fields and correctly does not.
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 would be 3, but the description adds meaning the schema cannot: filters combine with AND, defaults (limit 50/max 100, sort_by 'volume_usd_24h', sort_dir 'desc'), the sort_by/order_by and sort_dir/sort alias relationships, accepted time formats for created_after, and that negatives are allowed for price-change filters. The '-24h' offset format and the short-window-returns-empty interaction with created_after are genuinely non-obvious.
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 names the sibling it differs from (getNetworkPools). The response envelope ('results', has_next_page, next_cursor) is stated up front, so an agent knows exactly what it gets back.
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 an explicit selection rule against the sibling ("Choose this over getNetworkPools when the user gives numeric constraints or a time window") plus three concrete example user phrasings. No inference is required to pick between the two tools.
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/idempotent/openWorld, but the description adds genuinely new context: keyless access, no pagination, no sorting, entire array returned in one shot. That tells the agent it cannot page or narrow results, which annotations alone would not convey.
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?
Front-loaded with what the tool returns, then where to go next, then use cases, then the getStats exclusion. Parenthetical asides and quoted query examples are dense with signal, not 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?
An output schema exists, so return-value detail is not required; the description still summarizes the row shape. Combined with keyless/no-pagination behavior and the slug-discovery workflow, nothing an agent needs before calling 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% and the single rationale parameter is fully documented in the schema, so the baseline is 3. The description still earns credit by asserting the tool "takes no parameters beyond a short rationale", implicitly confirming that no filter/sort/pagination params exist — useful for shaping expectations beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List every blockchain network DexPaprika indexes") and immediately names the fields each row carries (slug, 24h volume, tx count, pool count). This is clearly separable from getStats (platform totals) and getCapabilities, both named in the text.
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 framing ("Start here (or getCapabilities) to get the exact network slug that nearly every other tool requires") plus three representative user phrasings. It also names the exclusion: "For platform-wide totals rather than a per-network list use getStats."
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?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description still adds real context beyond them: 'keyless' (no auth needed), 'Returns live values only' (no historical data), and 'a single pool object (not a list)' which sets the return shape expectation.
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?
Front-loaded with purpose and return contents, then usage, then exclusions, then params — a sensible order with no filler sentences. Dense but every clause carries information; the inline param recap is the only slightly redundant part given the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained, yet the description still summarizes them briefly. Combined with the routing guidance to sibling tools and the explanation of the one non-obvious parameter, nothing an agent needs to call this correctly 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 baseline is 3. The description earns an extra point by explaining what 'inversed' actually does ('flips the token price ratio to token1/token0'), which is more concrete than the schema's 'Whether to invert the price ratio'. It omits the required 'rationale' parameter, but that is fully documented in the schema itself.
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?
Names a specific verb and resource ('Get the full current snapshot for one pool by address') and enumerates the returned fields, so an agent can distinguish it from list tools like getNetworkPools and time-series tools like getPoolOHLCV without opening the 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?
Gives explicit trigger contexts ('after search or getNetworkPools surfaces a pool', 'price/TVL of this pool?') and names both alternatives for off-scope needs: getPoolOHLCV for historical candles and getPoolTransactions for the raw swap feed. When-to-use and when-not-to-use are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a technical indicator (RSI, EMA, MACD, Bollinger Bands or VWAP) for one pool, computed server-side from the pool's completed OHLCV candles and returned as a time series. Read-only and keyless. Use for 'is this pool overbought?', 'RSI of this pair', 'MACD cross on the last candle', or as a ready-made signal input for a trading or screening agent, instead of fetching getPoolOHLCV and computing the indicator yourself. The indicator follows the pool's price as getPoolOHLCV reports it, with no inversed parameter. Values come oldest first, one per completed candle: rsi, ema and vwap return value; macd returns macd, signal and histogram; bbands returns upper, middle and lower. RSI over 70 is commonly read as overbought and under 30 as oversold; a MACD histogram that changes sign means MACD crossed its signal line. RSI, EMA and MACD are smoothed, so start at least ten periods before the first value you rely on. Params: network (required); pool_address (required); indicator (required): 'rsi', 'ema', 'macd', 'bbands' or 'vwap'; interval (pass it every time: '1m','5m','10m','15m','30m','1h','6h','12h','24h' or '1d'); start (optional; a relative offset such as '-24h' or '-7d', Unix seconds, RFC3339 or yyyy-mm-dd; without it you get the last limit values); end (optional, exclusive); limit (default 100, max 1000); cursor (next_cursor of the previous page, not with start); period for rsi (default 14), ema (20), bbands (20) and vwap (14); fast_period (12), slow_period (26) and signal_period (9) for macd only; std_dev (2) for bbands only. A parameter that belongs to another indicator is refused. This server computes them from what a free DexPaprika key gets: interval '10m' or longer and history within the last 7 days, so a start further back, a finer interval or a cursor runs on the caller's own Dev, Pro or Enterprise key when the connection carries one (the Authorization header, the key on its own) and otherwise returns DP403_PLAN_REQUIRED, and without start the page holds only the values that fit in those 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | OPTIONAL: End of the range, exclusive, same formats as start. Defaults to now | |
| limit | No | OPTIONAL: Values per response (default 100, max 1000) | |
| start | No | OPTIONAL: First candle. A relative offset from now is simplest: '-24h', '-7d' (units s, m, h, d). Also Unix seconds, RFC3339 or YYYY-MM-DD. Without it you get the last `limit` values | |
| cursor | No | OPTIONAL: next_cursor from the previous page. Do not combine with start | |
| period | No | OPTIONAL: rsi (default 14), ema (default 20), bbands (default 20), vwap (default 14). Not for macd | |
| network | Yes | REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana') | |
| std_dev | No | OPTIONAL, bbands only: band width in standard deviations (default 2) | |
| interval | No | Candle interval the indicator is computed on. Pass it every time; '1d' equals '24h' | |
| indicator | Yes | REQUIRED: 'rsi', 'ema', 'macd', 'bbands' (Bollinger Bands) or 'vwap' | |
| 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. | |
| fast_period | No | OPTIONAL, macd only: fast EMA period (default 12) | |
| slow_period | No | OPTIONAL, macd only: slow EMA period (default 26), must be above fast_period | |
| pool_address | Yes | REQUIRED: Pool address or identifier | |
| signal_period | No | OPTIONAL, macd only: signal line period (default 9) |
| Name | Required | Description |
|---|---|---|
| data | Yes | One value per completed candle, oldest first. |
| network | No | |
| interval | No | |
| indicator | No | |
| parameters | No | Parameters used, defaults included. |
| next_cursor | No | Pass as cursor for the next page; empty on the last page. |
| pool_address | No | Set on pool indicators. |
| has_next_page | No | |
| token_address | No | Set on token indicators. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description is not carrying the safety burden; instead it adds operationally decisive facts the annotations cannot express: parameter-mismatch refusal, per-indicator return field sets, 7-day/free-key window, and the exact failure mode DP403_PLAN_REQUIRED when a finer interval or deeper start runs without a paid key. It also warns that smoothing requires leading periods before values are trustworthy, which materially changes how results should be read.
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?
Front-loaded with purpose, then usage, then return shape, then caveats — the ordering an agent needs. It is dense but not padded; the one inefficiency is the trailing parameter recap, which repeats defaults already documented at 100% schema coverage and could be trimmed without loss.
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 14-parameter, enum-bearing, plan-gated analytics tool, the description covers everything an agent needs to call it correctly: which param belongs to which indicator, paging vs. start exclusivity, output field names per indicator, and price-level interpretation guidance (RSI 70/30, MACD histogram sign change). An output schema exists, yet the description still names the per-indicator fields, which is surplus rather than a gap.
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 earns above that by adding cross-parameter rules the schema does not encode — 'a parameter that belongs to another indicator is refused', 'cursor ... not with start', and the default-window behavior ('without start you get the last limit values'). Its verbatim restatement of defaults and start formats largely duplicates the schema, keeping it off 5.
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?
Names a specific verb and resource ('Get a technical indicator ... for one pool') and enumerates the five supported indicators in parentheses. It also draws a hard line against the nearest sibling by stating the values follow the pool's price 'as getPoolOHLCV reports it, with no inversed parameter', so an agent can separate this from getPoolOHLCV and getTokenIndicator without opening a 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?
Gives concrete trigger utterances ('is this pool overbought?', 'RSI of this pair', 'MACD cross on the last candle') and an explicit alternative with a reason to prefer this tool: 'instead of fetching getPoolOHLCV and computing the indicator yourself'. Preconditions (keyless vs keyed, 7-day history, interval >= 10m on a free key) are stated up front rather than left to inference.
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; easiest as a relative offset from now such as '-24h' or '-7d', so you need not know today's date; also Unix seconds, RFC3339 or yyyy-mm-dd); end (optional); interval one of '1m','5m','10m','15m','30m','1h','6h','12h','24h' (default '24h'); limit (default 100, max 1000 candles); inversed (optional bool, default false). This server serves candles as a free DexPaprika key gets them: interval '10m' or longer, start and end within the last 7 days; outside that, it runs on the caller's own Dev, Pro or Enterprise key when the connection carries one (the Authorization header, the key on its own), and otherwise returns DP403_PLAN_REQUIRED and sends nothing upstream.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | OPTIONAL: End time for historical data, same formats as start (e.g. '-1h') | |
| limit | No | OPTIONAL: Number of OHLCV data points to retrieve (default: 100, max: 1000). One row per `interval`. | |
| start | Yes | REQUIRED: Start time. A relative offset from now is simplest and needs no knowledge of today's date: '-24h' (last 24 hours), '-7d', '-90m' (units s, m, h, d). Also accepts RFC3339 (e.g. '2024-01-01T00:00:00Z'), 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 read-only, idempotent, non-destructive behavior, but the description adds critical context beyond them: the free-tier key limits (interval '10m' or longer, start/end within 7 days), the fallback to caller-supplied Dev/Pro/Enterprise keys via Authorization header, and the DP403_PLAN_REQUIRED error otherwise. These are non-obvious operational constraints that materially affect invocation.
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 definition is dense but front-loads purpose, then alternatives, then parameters, then constraints. It is longer than ideal because the parameter list repeats schema details, but no sentence is wasted given the complexity of the tool and its plan constraints.
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 a rich output schema (time-series array), the description need not explain return values; it covers purpose, usage, parameters, and operational limits thoroughly. An agent has everything needed to call correctly or handle the plan-required error.
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; however, the description adds meaning by clarifying that start is easiest as a relative offset (so the caller need not know today's date) and by linking interval and start/end constraints to plan requirements. It largely echoes the schema but does so usefully and adds the key parameter-level constraint.
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 ('Get historical OHLCV candles ... for one pool over a time range') and distinguishes itself from the sibling getPoolDetails for current price. An agent can immediately tell what it returns and how it differs from adjacent 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?
Explicitly lists use cases ('price history of this pair', 'hourly chart for the last week', backtesting) and names the alternative (getPoolDetails) with the condition that selects it. This is exactly the when-to-use guidance needed.
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. Runs on the caller's own Dev, Pro or Enterprise API key, set as the Authorization header on the connection to this server; without one it returns DP401_API_KEY_REQUIRED and sends nothing upstream, and a free key gets 403. In either case getPoolDetails still gives the pool's 24h transaction counts and volume. 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, inclusive: a relative offset such as '-1h', Unix seconds, RFC3339 or YYYY-MM-DD; capped to the last 7 days); to (optional, exclusive, same formats, must be after from).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | OPTIONAL: Filter transactions up to this time (exclusive), same formats as from. Must be after 'from'. | |
| from | No | OPTIONAL: Filter transactions starting from this time (inclusive): a relative offset such as '-1h' or '-24h', Unix seconds, RFC3339 or YYYY-MM-DD. Results always capped to last 7 days. | |
| 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?
Annotations already cover read-only/idempotent, so the description is free to add what they cannot: API key tier requirements, the DP401_API_KEY_REQUIRED / 403 failure modes, no upstream request on missing key, the 7-day result cap, and newest-first ordering. That is substantial behavior beyond structured data.
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?
Front-loads the core action and output envelope, then auth, then sibling disambiguation, then params – a sensible order. It is dense and the middle auth sentence is long, but no sentence is 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?
Output schema exists so return shape needn't be explained, and auth, caps, and alternatives are all covered. The one gap is the required 'rationale' parameter, which is never mentioned in the description and is a server-wide convention an agent might otherwise skip.
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 'Params:' list largely restates what the schema already documents (defaults, page cap, from/to formats, exclusivity of 'to'). It gives a convenient single-line summary but adds no new semantics, so the baseline 3 applies.
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 ('get one pool's recent individual swap transactions, newest first') and explicitly distinguishes the output from getPoolOHLCV (aggregated candles) and getPoolDetails (summary snapshot). An agent can pick this tool without opening 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?
Names the alternatives with the conditions that select them, plus concrete trigger phrases ('recent trades on this pool', 'who swapped in the last hour'). It also prescribes a fallback path when auth fails ('in either case getPoolDetails still gives...'), which is exactly the routing guidance an agent needs.
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/idempotent/non-destructive, and the description adds 'keyless' access and the fact that results come back as a single summary object rather than a collection. It does not cover rate limits or refresh cadence, so it is strong but not exhaustive.
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?
Front-loads the purpose, then usage examples, then the sibling disambiguation. Four sentences, each carrying distinct information with no restatement of the name.
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?
An output schema is present so return shape need not be explained, and the description covers scope, safety posture, access requirements, and alternatives. Nothing needed to invoke this zero-filter tool correctly 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 rationale parameter is fully documented in the schema itself; the description's note that the tool 'takes no parameters beyond a short rationale' usefully confirms no filter arguments exist. That is additive but thin beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get platform-wide totals ... number of networks, DEXes, pools, and tokens indexed') and explicitly scopes it as ecosystem-wide rather than per-chain. This directly separates it from getNetworks, which the description names.
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 concrete example queries ('how much data do you cover?', 'how many chains or pools total?') plus explicit routing to getNetworks for per-chain breakdowns and getCapabilities for onboarding docs. Both the when-to-use and the alternatives are spelled out.
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, idempotentHint, and destructiveHint=false, so safety is covered. The description still adds useful operational context — 'keyless' (no auth needed) and that the result is a single token object rather than a list — which goes beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose, then routing guidance, then alternatives. Slightly padded by the trailing 'Params:' sentence that repeats schema content already covered elsewhere.
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?
Returned fields are summarized even though an output schema exists, usage conditions and prerequisites are covered, and the keyless/read-only nature is stated. Nothing needed to invoke it correctly 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 both required params are already documented with examples in the schema. The description's param recap adds only a light restatement ('network required slug') and doesn't explain the required rationale param, so it sits at the baseline.
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?
Specific verb plus resource (single token's data/metadata by contract address on a network) and enumerates the returned fields (price/volume, name, site, socials). It clearly distinguishes itself from getTokenMultiPrices and getTokenPools by name.
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 concrete use-case phrasings ('price and volume for 0x... on Base'), a prerequisite path for symbol-only lookups (call search first), and explicit alternatives for bulk prices and pool data. When/when-not routing is fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a technical indicator (RSI, EMA, MACD, Bollinger Bands or VWAP) for one token, computed server-side from the token's USD candles across every pool it trades in on the network (the same series as getTokenOHLCV), returned as a time series. Read-only. Runs on the caller's own Dev, Pro or Enterprise API key, set as the Authorization header on the connection to this server; without one it returns DP401_API_KEY_REQUIRED and sends nothing upstream, and a free key gets 403. In either case fall back to getPoolIndicator on the token's most liquid pool, found with getTokenPools sorted by volume. Values come oldest first, one per completed candle: rsi, ema and vwap return value; macd returns macd, signal and histogram; bbands returns upper, middle and lower. RSI over 70 is commonly read as overbought and under 30 as oversold; a MACD histogram that changes sign means MACD crossed its signal line. RSI, EMA and MACD are smoothed, so start at least ten periods before the first value you rely on. Params: network (required); token_address (required); indicator (required): 'rsi', 'ema', 'macd', 'bbands' or 'vwap'; interval (pass it every time: '1m','5m','10m','15m','30m','1h','6h','12h','24h' or '1d'); start (optional; a relative offset such as '-24h' or '-7d', Unix seconds, RFC3339 or yyyy-mm-dd; without it you get the last limit values); end (optional, exclusive); limit (default 100, max 1000); cursor (next_cursor of the previous page, not with start); period for rsi (default 14), ema (20), bbands (20) and vwap (14); fast_period (12), slow_period (26) and signal_period (9) for macd only; std_dev (2) for bbands only. A parameter that belongs to another indicator is refused.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | OPTIONAL: End of the range, exclusive, same formats as start. Defaults to now | |
| limit | No | OPTIONAL: Values per response (default 100, max 1000) | |
| start | No | OPTIONAL: First candle. A relative offset from now is simplest: '-24h', '-7d' (units s, m, h, d). Also Unix seconds, RFC3339 or YYYY-MM-DD. Without it you get the last `limit` values | |
| cursor | No | OPTIONAL: next_cursor from the previous page. Do not combine with start | |
| period | No | OPTIONAL: rsi (default 14), ema (default 20), bbands (default 20), vwap (default 14). Not for macd | |
| network | Yes | REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana') | |
| std_dev | No | OPTIONAL, bbands only: band width in standard deviations (default 2) | |
| interval | No | Candle interval the indicator is computed on. Pass it every time; '1d' equals '24h' | |
| indicator | Yes | REQUIRED: 'rsi', 'ema', 'macd', 'bbands' (Bollinger Bands) or 'vwap' | |
| 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. | |
| fast_period | No | OPTIONAL, macd only: fast EMA period (default 12) | |
| slow_period | No | OPTIONAL, macd only: slow EMA period (default 26), must be above fast_period | |
| signal_period | No | OPTIONAL, macd only: signal line period (default 9) | |
| token_address | Yes | REQUIRED: Token contract address |
| Name | Required | Description |
|---|---|---|
| data | Yes | One value per completed candle, oldest first. |
| network | No | |
| interval | No | |
| indicator | No | |
| parameters | No | Parameters used, defaults included. |
| next_cursor | No | Pass as cursor for the next page; empty on the last page. |
| pool_address | No | Set on pool indicators. |
| has_next_page | No | |
| token_address | No | Set on token indicators. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses authentication behavior, specific error codes, that no upstream request is sent without a valid key, and the fallback path. It also explains return-value semantics for each indicator and warns that RSI, EMA, and MACD are smoothed, so at least ten periods of warm-up are needed before relying on values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then auth/fallback, return semantics, and parameter notes, so an agent can extract the key constraints quickly. It is still long and repeats several schema details, which keeps it from being maximally concise.
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 14-parameter tool with an output schema, the description covers the critical context an agent needs: auth requirements, error behavior, fallback strategy, indicator output fields, smoothing caveats, and indicator-specific parameter rules. Nothing important for correct invocation appears 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 baseline is 3. The description restates many schema details but adds useful cross-parameter meaning, especially that interval should be passed every time and that a parameter belonging to another indicator is refused, plus an integrated summary of which parameters apply to which indicator.
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 a technical indicator (RSI, EMA, MACD, Bollinger Bands, or VWAP) for one token, computed server-side across all pools and returned as a time series. It also distinguishes the token-wide series from getTokenOHLCV and explicitly routes to the sibling getPoolIndicator in fallback cases.
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 when-not guidance tied to API key availability: without a paid key it returns DP401_API_KEY_REQUIRED and sends nothing upstream, while a free key gets 403. It then names the alternative and how to use it: fall back to getPoolIndicator on the token's most liquid pool, found with getTokenPools sorted by volume.
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 declare readOnly, idempotent, non-destructive and openWorld, so the 'read-only' phrasing is partially redundant. However, the description adds genuinely new behavior: it is keyless, it batches up to 10 tokens on one network, and failed tokens surface in missing_tokens instead of being dropped, which tells the agent to handle partial failures.
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?
Front-loaded with the core behavior and failure semantics before use cases and the sibling pointer. Slightly dense with three example phrasings, but each sentence carries actionable content.
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?
An output schema exists, so return shape needn't be spelled out, and the description still notes the two top-level keys. Rich annotations plus full schema coverage mean the remaining gap is minor: the required rationale convention is only referenced indirectly.
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 reinforces the shared-network constraint and the 1-10 address range, but it omits the required `rationale` parameter entirely, leaving that convention to the schema and server instructions.
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 with scope: batched USD prices for up to 10 tokens on one network, returned as a prices array plus missing_tokens. It also explicitly names getTokenDetails as the sibling for single-token metadata, so the agent can differentiate 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?
Gives concrete trigger phrasings ('prices for these tokens', 'compare the price of X, Y and Z', portfolio snapshot) and an explicit exclusion rule routing single-token multi-timeframe requests to getTokenDetails. Both when-to-use and when-not are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical USD OHLCV candles for one token over a time range, returned as a time-series array. The price and volume are computed across every pool the token trades in on the network (a volume-weighted price, and volume summed across those pools), not a single pair. Runs on the caller's own Dev, Pro or Enterprise API key, set as the Authorization header on the connection to this server; without one it returns DP401_API_KEY_REQUIRED and sends nothing upstream, and a free key gets 403. In either case fall back to getPoolOHLCV on the token's main pool, found with getTokenPools sorted by volume. Use for 'price history of this token' or 'USD chart for this token'; for a single pair's candles use getPoolOHLCV, and for the current price use getTokenDetails. Params: network (required); token_address (required); start (required; easiest as a relative offset from now such as '-24h', so you need not know today's date; also Unix seconds, RFC3339 or yyyy-mm-dd); end (optional, same formats); interval one of '1m','5m','10m','15m','30m','1h','6h','12h','24h' (default '24h'); limit (default 10, max 1000 candles). Dev plan history is limited to the last 30 days. There is no inversed parameter on this endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | OPTIONAL: End time, same formats as start (e.g. '-1h') | |
| limit | No | OPTIONAL: Number of data points to retrieve (default: 10, max: 1000) | |
| start | Yes | REQUIRED: Start time. A relative offset from now is simplest and needs no knowledge of today's date: '-24h' (last 24 hours), '-7d', '-90m' (units s, m, h, d). Also accepts RFC3339 (e.g. '2024-01-01T00:00:00Z'), 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 |
| 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 |
| Name | Required | Description |
|---|---|---|
| ohlcv | Yes | USD candles for the token across all its pools, ordered by time_open ascending. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds genuine value beyond that: auth requirements (own Dev/Pro/Enterprise key in Authorization header), failure modes (DP401_API_KEY_REQUIRED sends nothing upstream, 403 on free keys), and the Dev-plan 30-day history cap. This is strong supplemental context, though it stops short of return-shape or pagination detail (which the output schema covers).
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?
Scope and aggregation are front-loaded, then alternatives, then auth failure modes, then params – a logical ordering. It is dense and a touch run-on in the auth/fallback clause, but each sentence carries actionable information with little redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-param tool with an output schema, the description covers purpose, aggregation semantics, auth prerequisites, failure recovery, plan limits, and all parameter edge notes. Return values are handled by the output schema, 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?
Schema coverage is 100%, so the schema already documents all params. The description adds operational meaning beyond it: relative-offset advice for start ('-24h' so you needn't know today's date), the enumerated intervals with default, limit default/max, and the notable 'no inversed parameter' caveat. This goes slightly past the schema restatement.
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+resource ('Get historical USD OHLCV candles for one token over a time range') and immediately clarifies the aggregation scope (cross-pool VWAP + summed volume, not a single pair). It explicitly differentiates from siblings by naming getPoolOHLCV for single pairs and getTokenDetails for current price.
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 triggers ('price history of this token', 'USD chart'), names the alternatives with their selecting conditions (getPoolOHLCV for a single pair, getTokenDetails for current price), and even gives a fallback path via getTokenPools sorted by volume when auth fails.
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 readOnly/idempotent/non-destructive/openWorld, but the description adds genuinely new context: keyless access, network scoping, empty-results-not-error semantics, pagination via has_next_page/next_cursor, and that extra params like inversed or paired_token_address throw an error. That is exactly the beyond-annotation disclosure this dimension rewards.
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?
Front-loaded with purpose, return shape, and usage, then a compressed param digest. The final param sentence is dense and partially redundant with the schema, keeping it from a 5, but nothing is wasted at the sentence level.
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 present and 100% param coverage, the description need only supply routing and behavioral context, and it does: scope, return envelope, pagination, error behavior, and the sibling to use for token price. Nothing an agent needs to invoke it correctly 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 already documents every parameter, default, enum, and alias. The description's param sentence restates defaults, aliases, and the unsupported-param error, which is convenient but largely duplicative of structured data already in the schema; the alias warnings are the only marginal addition.
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 ('liquidity pools that contain a specific token on one network'), names the response envelope key 'results', and gives concrete example queries. It also distinguishes itself from getTokenDetails, so an agent can route between them 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?
Explicit when-to-use examples ('which pools hold WETH on ethereum?'), a prerequisite rule ('run search first if unsure of the network'), and a named alternative ('For the token's own price use getTokenDetails'). Also states that unknown addresses return empty results rather than an error, which matters for retry decisions.
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?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds 'keyless' auth context, the response envelope ('results', has_next_page, next_cursor), and the non-obvious quirk that ranking by raw price silently falls back to volume. That fallback disclosure is real value beyond structured fields, though some return-shape detail overlaps the output schema.
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 and examples are front-loaded before parameters, and each sentence carries information. It is a dense single paragraph; the param recap could be trimmed since the schema already covers it, but nothing is 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 paged, sortable read-only listing with full schema coverage, annotations, and an output schema, the description supplies everything an agent needs: scope, examples, the alternative tool, pagination chaining, and the sort fallback caveat.
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 every parameter (limit default/max, cursor paging, sort_by enum, alias pairs) is already documented in the input schema. The description restates the same facts (defaults, aliases, price fallback) without adding format or precedence rules the schema lacks, so baseline 3 applies.
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 (get) plus resource (top tokens on one network) plus the ranking dimensions supported, and names the sibling it is not (filterNetworkTokens). An agent can distinguish it from the other 19 siblings without opening a 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?
Gives concrete query patterns ('top gainers on Solana', 'highest-volume tokens on Base') and an explicit exclusion: arbitrary numeric filters or a time window belong to filterNetworkTokens. The routing decision is fully resolved in the text.
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?'. Several words work: 'WETH USDC' returns the pools pairing both, and a network name ('brett base') narrows results to that chain. 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', 'WETH USDC', 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 readOnly, idempotent, openWorld, and non-destructive. The description adds context beyond those: keyless operation, the exact return shape (three named arrays), client-side limit application, and the important no-match behavior (empty arrays rather than an error). This is meaningful behavioral disclosure.
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?
Front-loads scope and return shape, then routing guidance, then examples, then parameter summary. Every sentence adds distinct value; the multi-word query semantics ('WETH USDC', 'brett base') are non-obvious and earn their space.
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 cross-chain search tool with an output schema and full annotation coverage, the description supplies everything an agent needs: scope, routing, return shape, empty-result semantics, and multi-token query behavior. Nothing material 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 already documents query, its examples, and limit's client-side behavior. The description mirrors some of that but adds no syntax or format details absent from the schema, and it omits the required rationale parameter entirely. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Search'), resource ('tokens, pools, and DEXes'), and scope ('across ALL networks at once'), and explicitly contrasts itself with network-scoped sibling tools. An agent can distinguish it from getTokenDetails or getNetworkPools without opening 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 names the situation to use it ('when you do not yet know which network something lives on') and the transition condition to alternatives ('once you have a network slug ... switch to the network-scoped tools'). Provides concrete example queries that map real user intents to this tool.
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 declare this is a non-read-only, non-idempotent, non-destructive, closed-world write, and the description is consistent with that. It adds real context beyond the annotations: submissions are read by humans, partial feedback is accepted, and the expected/observed framing replaces a rationale field. It stops short of covering rate limits, duplicate handling, or whether ambient context is auto-attached.
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?
Two sentences, front-loaded with the action and followed by the triggering conditions. 'Every submission is read' slightly overlaps with 'even partial feedback helps' but both serve as encouragement, so the redundancy is mild rather than wasteful.
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?
Output schema exists and all six parameters are documented, so the description needn't explain returns or field formats. It covers the why and when well; only secondary details — duplicate submissions, rate limits, what metadata travels with the report — are absent, which are minor for an optional feedback channel.
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% and each field already carries its own constraints and rationale, so the schema does the heavy lifting. The description only names the goal/expected/observed trio and notes the absence of a rationale field, adding little beyond what's structured. 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?
Names a specific verb+resource (report a problem to the DexPaprika team) and enumerates the triggering conditions — stuck, unexpected return, missing data, undocumented behavior. This is clearly distinguishable from every sibling tool, which are all read/query 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?
Explicitly states when to invoke: 'Use whenever you hit a dead end, a response shape surprised you, or coverage was missing.' It also preempts the most common hesitation ('even partial feedback helps'), giving the agent a clear green light rather than leaving judgment to inference.
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.
filterNetworkTokens8 fields changedOutput schema / properties / has_next_page / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / query / additionalPropertiesRemoved value: -{}Output schema / properties / query / anyOfAdded value: +[
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / query / typeRemoved value: -"object"Output schema / properties / results / items / additionalPropertiesRemoved value: -trueOutput schema / properties / results / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "chain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "decimals": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / results / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / results / items / typeRemoved value: -"object"getCapabilities24 fields changedOutput schema / properties / agent_skills / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / common_pitfalls / items / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / documentation / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / network_synonyms / additionalPropertiesRemoved value: -{
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / properties / network_synonyms / anyOfAdded value: +[
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "items": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / network_synonyms / typeRemoved value: -"object"Output schema / properties / rate_limits / additionalPropertiesRemoved value: -trueOutput schema / properties / rate_limits / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "basis": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "on_limit": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "own_key_note": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "own_key_tools": {
+ "anyOf": [
+ {
+ "items": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "rest_api_limits_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "basis",
+ "on_limit",
+ "own_key_tools",
+ "own_key_note",
+ "rest_api_limits_url"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / rate_limits / propertiesRemoved value: -{
- "basis": {
- "type": "string"
- },
- "on_limit": {
- "type": "string"
- },
- "own_key_note": {
- "type": "string"
- },
- "own_key_tools": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "rest_api_limits_url": {
- "type": "string"
- }
-}Output schema / properties / rate_limits / requiredRemoved value: -[
- "basis",
- "on_limit",
- "own_key_tools",
- "own_key_note",
- "rest_api_limits_url"
-]Output schema / properties / rate_limits / typeRemoved value: -"object"Output schema / properties / server / additionalPropertiesRemoved value: -trueOutput schema / properties / server / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "version": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "version"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / server / propertiesRemoved value: -{
- "name": {
- "type": "string"
- },
- "version": {
- "type": "string"
- }
-}Output schema / properties / server / requiredRemoved value: -[
- "name",
- "version"
-]Output schema / properties / server / typeRemoved value: -"object"Output schema / properties / stats / additionalPropertiesRemoved value: -trueOutput schema / properties / stats / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "console_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "docs_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "free_key_credits_per_month": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "free_key_requests_per_minute": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "free_tier": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "free_tier_credits_per_month": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "free_tier_max_data_delay_seconds": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "free_tier_requests_per_minute": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "key_required_to_start": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "networks": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "pools_approx": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "pricing_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "tokens_approx": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "networks",
+ "tokens_approx",
+ "pools_approx",
+ "free_tier",
+ "key_required_to_start"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / stats / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / stats / requiredRemoved value: -[
- "networks",
- "tokens_approx",
- "pools_approx",
- "free_tier",
- "key_required_to_start"
-]Output schema / properties / stats / typeRemoved value: -"object"Output schema / properties / workflows / additionalPropertiesRemoved value: -{
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / properties / workflows / anyOfAdded value: +[
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "items": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / workflows / typeRemoved value: -"object"getDexPools8 fields changedOutput schema / properties / has_next_page / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / query / additionalPropertiesRemoved value: -{}Output schema / properties / query / anyOfAdded value: +[
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / query / typeRemoved value: -"object"Output schema / properties / results / items / additionalPropertiesRemoved value: -trueOutput schema / properties / results / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "description": "ISO 8601 pool-creation timestamp.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at_block_number": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "dex_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "dex_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fee": {
+ "description": "Pool fee (units depend on DEX; null for some DEXes).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Pool contract address.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "last_price_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tokens": {
+ "anyOf": [
+ {
+ "items": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "chain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "decimals": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / results / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / results / items / typeRemoved value: -"object"getNetworkDexes8 fields changedOutput schema / properties / dexes / items / additionalPropertiesRemoved value: -trueOutput schema / properties / dexes / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "dex_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "dex_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "display_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "network_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "pools_count": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "protocol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "txns_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_usd_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / dexes / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / dexes / items / typeRemoved value: -"object"Output schema / properties / page_info / additionalPropertiesRemoved value: -trueOutput schema / properties / page_info / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "limit": {
+ "description": "Items per page in the request.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "page": {
+ "description": "Current page number (1-indexed).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_items": {
+ "description": "Total number of items across all pages.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_pages": {
+ "description": "Total number of pages available.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / page_info / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / page_info / typeRemoved value: -"object"getNetworkPools8 fields changedOutput schema / properties / has_next_page / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / query / additionalPropertiesRemoved value: -{}Output schema / properties / query / anyOfAdded value: +[
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / query / typeRemoved value: -"object"Output schema / properties / results / items / additionalPropertiesRemoved value: -trueOutput schema / properties / results / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "description": "ISO 8601 pool-creation timestamp.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at_block_number": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "dex_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "dex_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fee": {
+ "description": "Pool fee (units depend on DEX; null for some DEXes).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Pool contract address.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "last_price_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tokens": {
+ "anyOf": [
+ {
+ "items": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "chain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "decimals": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / results / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / results / items / typeRemoved value: -"object"getNetworkPoolsFilter8 fields changedOutput schema / properties / has_next_page / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / query / additionalPropertiesRemoved value: -{}Output schema / properties / query / anyOfAdded value: +[
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / query / typeRemoved value: -"object"Output schema / properties / results / items / additionalPropertiesRemoved value: -trueOutput schema / properties / results / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "description": "ISO 8601 pool-creation timestamp.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at_block_number": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "dex_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "dex_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fee": {
+ "description": "Pool fee (units depend on DEX; null for some DEXes).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Pool contract address.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "last_price_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tokens": {
+ "anyOf": [
+ {
+ "items": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "chain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "decimals": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / results / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / results / items / typeRemoved value: -"object"getNetworks4 fields changedOutput schema / properties / networks / items / additionalPropertiesRemoved value: -trueOutput schema / properties / networks / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "display_name": {
+ "description": "Human-readable network name (e.g. 'Ethereum').",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Network slug for use in other endpoints (e.g. 'ethereum').",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "pools_count": {
+ "description": "Number of indexed pools on this network.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "txns_24h": {
+ "description": "Total transactions in the last 24h on this network.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_usd_24h": {
+ "description": "Total 24h trading volume across all pools on this network, USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / networks / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / networks / items / typeRemoved value: -"object"getPoolDetails12 fields changedOutput schema / properties / chain / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / created_at / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / created_at_block_number / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / dex_id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / dex_name / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / factory_id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / price_time / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / tokens / items / additionalPropertiesRemoved value: -trueOutput schema / properties / tokens / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "chain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "decimals": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / tokens / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / tokens / items / typeRemoved value: -"object"getPoolIndicator15 fields changedOutput schema / properties / data / items / additionalPropertiesRemoved value: -trueOutput schema / properties / data / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "histogram": {
+ "description": "macd minus signal; a sign change is a crossover.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "lower": {
+ "description": "bbands lower band.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "macd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "middle": {
+ "description": "bbands middle band (the moving average).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "signal": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "timestamp": {
+ "description": "Open time of the candle, RFC3339.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "upper": {
+ "description": "bbands upper band.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "description": "rsi, ema and vwap.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "timestamp"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / items / propertiesRemoved value: -{
- "histogram": {
- "description": "macd minus signal; a sign change is a crossover.",
- "type": "number"
- },
- "lower": {
- "description": "bbands lower band.",
- "type": "number"
- },
- "macd": {
- "type": "number"
- },
- "middle": {
- "description": "bbands middle band (the moving average).",
- "type": "number"
- },
- "signal": {
- "type": "number"
- },
- "timestamp": {
- "description": "Open time of the candle, RFC3339.",
- "type": "string"
- },
- "upper": {
- "description": "bbands upper band.",
- "type": "number"
- },
- "value": {
- "description": "rsi, ema and vwap.",
- "type": "number"
- }
-}Output schema / properties / data / items / requiredRemoved value: -[
- "timestamp"
-]Output schema / properties / data / items / typeRemoved value: -"object"Output schema / properties / has_next_page / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / indicator / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / interval / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / network / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / next_cursor / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / parameters / additionalPropertiesRemoved value: -{}Output schema / properties / parameters / anyOfAdded value: +[
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / parameters / typeRemoved value: -"object"Output schema / properties / pool_address / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / token_address / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]getPoolOHLCV4 fields changedOutput schema / properties / ohlcv / items / additionalPropertiesRemoved value: -trueOutput schema / properties / ohlcv / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "close": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "high": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "low": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "open": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "time_close": {
+ "description": "ISO 8601 timestamp of bucket close (inclusive at 23:59:59 for 24h).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "time_open": {
+ "description": "ISO 8601 timestamp of bucket open.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "volume": {
+ "description": "Trade volume in the bucket, in pair-quote units (or USD where applicable).",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / ohlcv / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / ohlcv / items / typeRemoved value: -"object"getPoolTransactions8 fields changedOutput schema / properties / page_info / additionalPropertiesRemoved value: -trueOutput schema / properties / page_info / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "limit": {
+ "description": "Items per page in the request.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "page": {
+ "description": "Current page number (1-indexed).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_items": {
+ "description": "Total number of items across all pages.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_pages": {
+ "description": "Total number of pages available.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / page_info / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / page_info / typeRemoved value: -"object"Output schema / properties / transactions / items / additionalPropertiesRemoved value: -trueOutput schema / properties / transactions / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "amount_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "block_number": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "block_timestamp": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "pool_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "token0": {},
+ "token1": {}
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / transactions / items / propertiesRemoved value: -{
- "amount_usd": {
- "type": "number"
- },
- "block_number": {
- "type": "number"
- },
- "block_timestamp": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "pool_id": {
- "type": "string"
- },
- "token0": {},
- "token1": {}
-}Output schema / properties / transactions / items / typeRemoved value: -"object"getStats4 fields changedOutput schema / properties / chains / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / factories / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / pools / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / tokens / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]getTokenDetails11 fields changedOutput schema / properties / added_at / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / chain / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / decimals / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / description / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / has_image / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / name / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / symbol / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / total_supply / anyOfAdded value: +[
+ {
+ "type": [
+ "number",
+ "string"
+ ]
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / total_supply / typeRemoved value: -[
- "number",
- "string"
-]Output schema / properties / website / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]getTokenIndicator15 fields changedOutput schema / properties / data / items / additionalPropertiesRemoved value: -trueOutput schema / properties / data / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "histogram": {
+ "description": "macd minus signal; a sign change is a crossover.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "lower": {
+ "description": "bbands lower band.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "macd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "middle": {
+ "description": "bbands middle band (the moving average).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "signal": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "timestamp": {
+ "description": "Open time of the candle, RFC3339.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "upper": {
+ "description": "bbands upper band.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "description": "rsi, ema and vwap.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "timestamp"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / items / propertiesRemoved value: -{
- "histogram": {
- "description": "macd minus signal; a sign change is a crossover.",
- "type": "number"
- },
- "lower": {
- "description": "bbands lower band.",
- "type": "number"
- },
- "macd": {
- "type": "number"
- },
- "middle": {
- "description": "bbands middle band (the moving average).",
- "type": "number"
- },
- "signal": {
- "type": "number"
- },
- "timestamp": {
- "description": "Open time of the candle, RFC3339.",
- "type": "string"
- },
- "upper": {
- "description": "bbands upper band.",
- "type": "number"
- },
- "value": {
- "description": "rsi, ema and vwap.",
- "type": "number"
- }
-}Output schema / properties / data / items / requiredRemoved value: -[
- "timestamp"
-]Output schema / properties / data / items / typeRemoved value: -"object"Output schema / properties / has_next_page / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / indicator / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / interval / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / network / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / next_cursor / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / parameters / additionalPropertiesRemoved value: -{}Output schema / properties / parameters / anyOfAdded value: +[
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / parameters / typeRemoved value: -"object"Output schema / properties / pool_address / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / token_address / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]getTokenMultiPrices5 fields changedOutput schema / properties / missing_tokens / items / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / prices / items / additionalPropertiesRemoved value: -trueOutput schema / properties / prices / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "price_usd": {
+ "description": "Current USD price; null if not available.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / prices / items / propertiesRemoved value: -{
- "chain": {
- "type": "string"
- },
- "id": {
- "description": "Token contract address.",
- "type": "string"
- },
- "price_usd": {
- "description": "Current USD price; null if not available.",
- "type": [
- "number",
- "null"
- ]
- }
-}Output schema / properties / prices / items / typeRemoved value: -"object"getTokenOHLCV4 fields changedOutput schema / properties / ohlcv / items / additionalPropertiesRemoved value: -trueOutput schema / properties / ohlcv / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "close": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "high": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "low": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "open": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "time_close": {
+ "description": "ISO 8601 timestamp of bucket close (inclusive at 23:59:59 for 24h).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "time_open": {
+ "description": "ISO 8601 timestamp of bucket open.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "volume": {
+ "description": "Trade volume in the bucket, in pair-quote units (or USD where applicable).",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / ohlcv / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / ohlcv / items / typeRemoved value: -"object"getTokenPools8 fields changedOutput schema / properties / has_next_page / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / query / additionalPropertiesRemoved value: -{}Output schema / properties / query / anyOfAdded value: +[
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / query / typeRemoved value: -"object"Output schema / properties / results / items / additionalPropertiesRemoved value: -trueOutput schema / properties / results / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "description": "ISO 8601 pool-creation timestamp.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at_block_number": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "dex_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "dex_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fee": {
+ "description": "Pool fee (units depend on DEX; null for some DEXes).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Pool contract address.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "last_price_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tokens": {
+ "anyOf": [
+ {
+ "items": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "chain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "decimals": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / results / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / results / items / typeRemoved value: -"object"getTopTokens8 fields changedOutput schema / properties / has_next_page / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / query / additionalPropertiesRemoved value: -{}Output schema / properties / query / anyOfAdded value: +[
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / query / typeRemoved value: -"object"Output schema / properties / results / items / additionalPropertiesRemoved value: -trueOutput schema / properties / results / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "chain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "decimals": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / results / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / results / items / typeRemoved value: -"object"search12 fields changedOutput schema / properties / dexes / items / additionalPropertiesRemoved value: -trueOutput schema / properties / dexes / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "dex_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "dex_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "display_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "network_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "pools_count": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "protocol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "txns_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_usd_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / dexes / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / dexes / items / typeRemoved value: -"object"Output schema / properties / pools / items / additionalPropertiesRemoved value: -trueOutput schema / properties / pools / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "chain": {
+ "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "description": "ISO 8601 pool-creation timestamp.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at_block_number": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "dex_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "dex_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fee": {
+ "description": "Pool fee (units depend on DEX; null for some DEXes).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Pool contract address.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "last_price_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tokens": {
+ "anyOf": [
+ {
+ "items": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "chain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "decimals": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / pools / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / pools / items / typeRemoved value: -"object"Output schema / properties / tokens / items / additionalPropertiesRemoved value: -trueOutput schema / properties / tokens / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "added_at": {
+ "description": "ISO 8601 timestamp when DexPaprika first indexed this token.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "chain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "decimals": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fdv": {
+ "description": "Fully-diluted valuation in USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Token contract address (chain-canonical form).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / tokens / items / propertiesRemoved value: -{
- "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"
- }
-}Output schema / properties / tokens / items / typeRemoved value: -"object"submitFeedback5 fields changedOutput schema / properties / message / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / ok / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / severity / anyOfAdded value: +[
+ {
+ "enum": [
+ "blocker",
+ "major",
+ "minor",
+ "nit"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / severity / enumRemoved value: -[
- "blocker",
- "major",
- "minor",
- "nit"
-]Output schema / properties / severity / typeRemoved value: -"string"submitFeedback3 fields changedInput schema / properties / attempted_tools / items / maxLengthAdded value: +100Input schema / properties / attempted_tools / maxItemsAdded value: +50Input schema / properties / blocked_at / maxLengthAdded value: +200getPoolIndicatorgetTokenIndicatorgetDexPools2 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",
+ "price_change_percentage_48h",
+ "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",
- "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",
+ "price_change_percentage_48h",
+ "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",
- "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",
+ "price_change_percentage_48h",
+ "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",
- "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",
+ "price_change_percentage_48h",
+ "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"
+]getNetworkPoolsFilter4 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",
+ "price_change_percentage_48h",
+ "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_48h_maxAdded value: +{
+ "description": "OPTIONAL: Maximum 48h price change, in percent",
+ "type": "number"
+}Input schema / properties / price_change_percentage_48h_minAdded value: +{
+ "description": "OPTIONAL: Minimum 48h 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",
+ "price_change_percentage_48h",
+ "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",
- "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",
+ "price_change_percentage_48h",
+ "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",
- "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",
+ "price_change_percentage_48h",
+ "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"
+]search1 field changedInput schema / properties / query / descriptionPrevious value: -"REQUIRED: Search term (e.g., 'uniswap', 'bitcoin', 'ethereum', or a token address)."New value: +"REQUIRED: Search term (e.g., 'uniswap', 'bitcoin', 'ethereum', 'WETH USDC', or a token address)."getCapabilities1 field changedOutput schema / properties / rate_limitsAdded value: +{
+ "additionalProperties": true,
+ "description": "How limits work for hosted tool calls. Not the REST allowances: your own plan does not apply, except to own_key_tools.",
+ "properties": {
+ "basis": {
+ "type": "string"
+ },
+ "on_limit": {
+ "type": "string"
+ },
+ "own_key_note": {
+ "type": "string"
+ },
+ "own_key_tools": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "rest_api_limits_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "basis",
+ "on_limit",
+ "own_key_tools",
+ "own_key_note",
+ "rest_api_limits_url"
+ ],
+ "type": "object"
+}getTokenOHLCVfilterNetworkTokens4 fields changedInput schema / properties / created_after / descriptionPrevious value: -"OPTIONAL: Only tokens created after this UNIX timestamp"New value: +"OPTIONAL: Only tokens created at or after this time: a relative offset such as '-24h' or '-7d', Unix seconds, RFC3339 or YYYY-MM-DD"Input schema / properties / created_after / typePrevious value: -"number"New value: +"string"Input schema / properties / created_before / descriptionPrevious value: -"OPTIONAL: Only tokens created before this UNIX timestamp"New value: +"OPTIONAL: Only tokens created at or before this time, same formats as created_after (e.g. '-1h')"Input schema / properties / created_before / typePrevious value: -"number"New value: +"string"getNetworkPoolsFilter4 fields changedInput schema / properties / created_after / descriptionPrevious value: -"OPTIONAL: Only pools created after this UNIX timestamp"New value: +"OPTIONAL: Only pools created at or after this time: a relative offset such as '-24h' or '-7d', Unix seconds, RFC3339 or YYYY-MM-DD"Input schema / properties / created_after / typePrevious value: -"number"New value: +"string"Input schema / properties / created_before / descriptionPrevious value: -"OPTIONAL: Only pools created before this UNIX timestamp"New value: +"OPTIONAL: Only pools created at or before this time, same formats as created_after (e.g. '-1h')"Input schema / properties / created_before / typePrevious value: -"number"New value: +"string"getPoolTransactions4 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: Filter transactions starting from this time (inclusive): a relative offset such as '-1h' or '-24h', Unix seconds, RFC3339 or YYYY-MM-DD. Results always capped to last 7 days."Input schema / properties / from / typePrevious value: -"number"New value: +"string"Input schema / properties / to / descriptionPrevious value: -"OPTIONAL: Filter transactions up to this UNIX timestamp (exclusive). Must be after 'from'."New value: +"OPTIONAL: Filter transactions up to this time (exclusive), same formats as from. Must be after 'from'."Input schema / properties / to / typePrevious value: -"number"New value: +"string"getPoolOHLCV3 fields changedInput schema / properties / end / descriptionPrevious value: -"OPTIONAL: End time for historical data (max 1 year from start)"New value: +"OPTIONAL: End time for historical data, same formats as start (e.g. '-1h')"Input schema / properties / limit / descriptionPrevious value: -"OPTIONAL: Number of OHLCV data points to retrieve (default: 100, max: 366). One row per `interval`."New value: +"OPTIONAL: Number of OHLCV data points to retrieve (default: 100, max: 1000). One row per `interval`."Input schema / properties / start / descriptionPrevious value: -"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)."New value: +"REQUIRED: Start time. A relative offset from now is simplest and needs no knowledge of today's date: '-24h' (last 24 hours), '-7d', '-90m' (units s, m, h, d). Also accepts RFC3339 (e.g. '2024-01-01T00:00:00Z'), Unix epoch seconds and YYYY-MM-DD (treated as 00:00:00 UTC)."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"
+}
Add one secure layer between your agents and this server.