Which integrations are available for this server?

Provides real-time access to DEX liquidity pool data on the BNB Chain network, enabling querying of new, trending, top pools, and searching pools by token name. Provides real-time access to DEX liquidity pool data on the Ethereum network, enabling querying of new, trending, top pools, and searching pools by token name. Provides real-time access to DEX liquidity pool data on the Polygon network, enabling querying of new, trending, top pools, and searching pools by token name.

How do I use DEX Pools MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DEX Pools MCP show me trending pools on Ethereum in the last 24h" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

DEX Pools MCP

by kukapay

Overview Schema Source Related Servers Discussions Admin

Python

Remote

DEX Pools MCP

An MCP server that provides AI agents with real-time access to DEX liquidity pool data, enabling smarter trading, analytics, and automated strategies.

GitHub License Python Version Status

Features

Query Supported Networks: Retrieve a list of supported blockchain networks on GeckoTerminal.
Query Supported DEXes: Fetch DEXes available on a specific network.
Fetch New Pools: List the latest pools across all networks or a specific network, with details like DEX, network, name, base price, reserve, volume, and address.
Fetch Trending Pools: Retrieve trending pools across all networks or a specific network, sorted by duration (5m, 1h, 6h, 24h).
Fetch Top Pools: Get top pools for a specific network or DEX, sorted by transaction count or volume.
Search Pools: Search for pools on a specific network using a query term (e.g., token name or symbol).

Related MCP server: Armor Crypto MCP

Prerequisites

Python 3.10 or higher
uv: Package and virtual environment manager for Python (recommended for dependency management).
A CoinGecko Demo API key (obtainable from coingecko.com)

Installation

Clone the Repository:

git clone https://github.com/kukapay/dex-pools-mcp.git
cd dex-pools-mcp

Install dependencies:
```
uv sync
```

Install to Claude Desktop:

Install the server as a Claude Desktop application:

uv run mcp install main.py --name "DEX Pools"

Configuration file as a reference:

{
   "mcpServers": {
       "DEX Pools": {
           "command": "uv",
           "args": [ "--directory", "/path/to/dex-pools-mcp", "run", "main.py" ],
           "env": { "COINGECKO_API_KEY": "coingecko_api_key"}
       }
   }
}

Replace /path/to/dex-pools-mcp with your actual installation path, and replace coingecko_api_key with your API key from CoinGecko.

Usage

Available Tools

The server provides the following tools, accessible via MCP clients (e.g., Claude Desktop) or the MCP Inspector:

get_supported_networks(page: int = 1): Returns a table of supported network IDs and names.
get_supported_dexes_by_network(network: str = "eth", page: int = 1): Returns a table of DEX IDs and names for a given network.
get_new_pools(page: int = 1, include: str = "base_token,quote_token,dex,network"): Returns a table of new pools across all networks with columns: DEX, Network, Name, Base Price (USD), Reserve (USD), Volume 24h (USD), Address.
get_new_pools_by_network(network: str = "eth", page: int = 1, include: str = "base_token,quote_token,dex,network"): Returns a table of new pools for a specific network with columns: DEX, Name, Base Price in Quote, Reserve (USD), Volume 24h (USD), Address.
get_trending_pools(page: int = 1, duration: str = "24h", include: str = "base_token,quote_token,dex,network"): Returns a table of trending pools across all networks with columns: DEX, Network, Name, Base Price in Quote, Reserve (USD), Volume 24h (USD), Address.
get_trending_pools_by_network(network: str = "eth", page: int = 1, duration: str = "24h", include: str = "base_token,quote_token,dex"): Returns a table of trending pools for a specific network.
get_top_pools_by_network(network: str = "eth", page: int = 1, sort: str = "h24_tx_count_desc", include: str = "base_token,quote_token,dex"): Returns a table of top pools for a specific network.
get_top_pools_by_dex(network: str = "eth", dex: str = "sushiswap", page: int = 1, sort: str = "h24_tx_count_desc", include: str = "base_token,quote_token,dex"): Returns a table of top pools for a specific DEX on a network.
search_pools(query: str = "weth", network: str = "eth", page: int = 1, include: str = "base_token,quote_token,dex"): Returns a table of pools matching a search query on a specific network.

Examples

Below are examples for each tool, including a natural language prompt and the expected output (mock data for illustration).

1. `get_supported_networks`

Prompt: "List the supported blockchain networks on GeckoTerminal for page 1."

Output:

+----------+-----------------+
| ID       | Name            |
+==========+=================+
| eth      | Ethereum        |
+----------+-----------------+
| bsc      | BNB Chain       |
+----------+-----------------+
| polygon  | Polygon         |
+----------+-----------------+

2. `get_supported_dexes_by_network`

Prompt: "Show me the DEXes available on the Ethereum network for page 1."

Output:

+--------------+-----------------+
| ID           | Name            |
+==============+=================+
| uniswap_v3   | Uniswap V3      |
+--------------+-----------------+
| sushiswap    | SushiSwap       |
+--------------+-----------------+
| pancakeswap  | PancakeSwap     |
+--------------+-----------------+

3. `get_new_pools`

Prompt: "Get the latest pools across all networks for page 1."

Output:

+--------------+----------+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| DEX          | Network  | Name              | Base Price (USD) | Reserve (USD) | Volume 24h (USD)  | Address                                     |
+==============+==========+===================+==================+===============+===================+=============================================+
| uniswap_v3   | eth      | WETH / USDC 0.05% | 3653.12          | 163988541.38  | 536545444.90      | 0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640 |
+--------------+----------+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| sushiswap    | bsc      | BNB / USDT        | 582.45           | 9876543.21    | 12345678.90       | 0x1234567890abcdef1234567890abcdef12345678 |
+--------------+----------+-------------------+------------------+---------------+-------------------+---------------------------------------------+

4. `get_new_pools_by_network`

Prompt: "List the latest pools on the Ethereum network for page 1."

Output:

+--------------+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| DEX          | Name              | Base Price       | Reserve (USD) | Volume 24h (USD)  | Address                                     |
+==============+===================+==================+===============+===================+=============================================+
| uniswap_v3   | WETH / USDC 0.05% | 3662.46          | 163988541.38  | 536545444.90      | 0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640 |
+--------------+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| sushiswap    | WETH / DAI        | 3650.00          | 8765432.10    | 9876543.21        | 0xabcdef1234567890abcdef1234567890abcdef12 |
+--------------+-------------------+------------------+---------------+-------------------+---------------------------------------------+

5. `get_trending_pools`

Prompt: "Show trending pools across all networks for the last 24 hours on page 1."

Output:

+--------------+----------+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| DEX          | Network  | Name              | Base Price       | Reserve (USD) | Volume 24h (USD)  | Address                                     |
+==============+==========+===================+==================+===============+===================+=============================================+
| uniswap_v3   | eth      | WETH / USDC 0.05% | 3662.46          | 163988541.38  | 536545444.90      | 0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640 |
+--------------+----------+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| pancakeswap  | bsc      | CAKE / BNB        | 2.34             | 5432109.87    | 8765432.10        | 0x7890abcdef1234567890abcdef1234567890abcd |
+--------------+----------+-------------------+------------------+---------------+-------------------+---------------------------------------------+

6. `get_trending_pools_by_network`

Prompt: "Get trending pools on the Ethereum network for the last 24 hours on page 1."

Output:

+--------------+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| DEX          | Name              | Base Price       | Reserve (USD) | Volume 24h (USD)  | Address                                     |
+==============+===================+==================+===============+===================+=============================================+
| uniswap_v3   | WETH / USDC 0.05% | 3662.46          | 163988541.38  | 536545444.90      | 0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640 |
+--------------+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| sushiswap    | WETH / DAI        | 3650.00          | 8765432.10    | 9876543.21        | 0xabcdef1234567890abcdef1234567890abcdef12 |
+--------------+-------------------+------------------+---------------+-------------------+---------------------------------------------+

7. `get_top_pools_by_network`

Prompt: "List the top pools on the Ethereum network sorted by transaction count for page 1."

Output:

+--------------+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| DEX          | Name              | Base Price       | Reserve (USD) | Volume 24h (USD)  | Address                                     |
+==============+===================+==================+===============+===================+=============================================+
| uniswap_v3   | WETH / USDC 0.05% | 3662.46          | 163988541.38  | 536545444.90      | 0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640 |
+--------------+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| sushiswap    | WETH / DAI        | 3650.00          | 8765432.10    | 9876543.21        | 0xabcdef1234567890abcdef1234567890abcdef12 |
+--------------+-------------------+------------------+---------------+-------------------+---------------------------------------------+

8. `get_top_pools_by_dex`

Prompt: "Show the top pools on SushiSwap for the Ethereum network, sorted by transaction count for page 1."

Output:

+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| Name              | Base Price       | Reserve (USD) | Volume 24h (USD)  | Address                                     |
+===================+==================+===============+===================+=============================================+
| WETH / DAI        | 3650.00          | 8765432.10    | 9876543.21        | 0xabcdef1234567890abcdef1234567890abcdef12 |
+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| SUSHI / WETH      | 1.23             | 4321098.76    | 5432109.87        | 0x1234567890abcdef1234567890abcdef12345678 |
+-------------------+------------------+---------------+-------------------+---------------------------------------------+

9. `search_pools`

Prompt: "Search for pools with 'WETH' on the Ethereum network for page 1."

Output:

+--------------+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| DEX          | Name              | Base Price       | Reserve (USD) | Volume 24h (USD)  | Address                                     |
+==============+===================+==================+===============+===================+=============================================+
| uniswap_v3   | WETH / USDC 0.05% | 3662.46          | 163988541.38  | 536545444.90      | 0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640 |
+--------------+-------------------+------------------+---------------+-------------------+---------------------------------------------+
| sushiswap    | WETH / DAI        | 3650.00          | 8765432.10    | 9876543.21        | 0xabcdef1234567890abcdef1234567890abcdef12 |
+--------------+-------------------+------------------+---------------+-------------------+---------------------------------------------+

License

This project is licensed under the MIT License. See the LICENSE file for details.

Available Tools

10 tools

get_new_poolsA

Query all the latest pools across all networks on GeckoTerminal and return a formatted table.

Args:
    page: Page number for pagination (default: 1)
    include: Comma-separated attributes to include (e.g., "base_token,quote_token,dex,network")

Returns:
    Formatted table as a string with columns: dex, network, name, base_price, reserve_usd, volume_usd_24h, address

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`include`	No		base_token,quote_token,dex,network

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a formatted table with specific columns and supports pagination, but does not mention safety traits like being read-only or non-destructive. More context about side effects or limitations would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, with the core purpose in the first sentence. Every sentence adds value: the first describes what the tool does, the second describes parameters. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple query tool with two optional parameters and an output schema (though not detailed), the description covers the return format and parameters. It could mention that it works exclusively on GeckoTerminal (implied by name) and handle error scenarios, but it is sufficiently complete for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains both parameters: 'Page number for pagination' and 'Comma-separated attributes to include' with an example. This adds meaning beyond the schema type 'integer' and 'string', compensating for the 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool queries 'all the latest pools across all networks on GeckoTerminal' and returns a formatted table. It uses a specific verb and resource, distinguishing it from sibling tools like get_new_pools_by_network and get_pool_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for getting all pools across networks, but does not explicitly state when not to use it or mention alternatives. For network-specific queries, the sibling get_new_pools_by_network exists, but no guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_new_pools_by_networkA

Query all the latest pools for a specific network on GeckoTerminal and return a formatted table.

Args:
    network: The network identifier (default: "eth" for Ethereum)
    page: Page number for pagination (default: 1)
    include: Comma-separated attributes to include (e.g., "base_token,quote_token,dex,network")

Returns:
    Formatted table as a string with columns: dex, name, base_price_in_quote, reserve_usd, volume_usd_24h, address

ParametersJSON Schema

Name	Required	Default
`network`	No	eth
`page`	No
`include`	No	base_token,quote_token,dex,network

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes return format but no annotations provided. No mention of read-only nature, rate limits, or side effects. For a query tool, basic transparency is lacking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise docstring with Args and Returns sections. Every sentence is necessary; no fluff. Efficiently conveys purpose and usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Return format is described with columns. However, lacks details on pagination behavior or default page size. Given tool simplicity, it is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, but description provides defaults and example values for network, page, and include parameters, adding significant value beyond schema types and titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it queries latest pools for a specific network and returns a formatted table. Differentiates from sibling tools like get_new_pools (no network filter) and get_top_pools_by_network (top vs latest).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for network-specific queries via parameter, but no explicit guidance on when to use this vs alternatives like get_new_pools or get_top_pools_by_network. No exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pool_detailsA

Query details for a specific pool on a network.

Args:
    network: The network identifier (e.g., "eth")
    pool_address: The pool contract address
    include: Comma-separated attributes to include

Returns:
    JSON string of the pool data

ParametersJSON Schema

Name	Required	Default
`network`	Yes
`pool_address`	Yes
`include`	No	base_token,quote_token,dex,network

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits. It only states it queries details, but does not mention that it is read-only, whether it requires authentication, rate limits, or what happens if the pool doesn't exist. This lack of transparency could lead to incorrect usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: one sentence for purpose followed by a clear list of parameters. Every word is useful and it is front-loaded with the main action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is an output schema, the return type is stated. However, the description lacks details on default include values, error behavior, or any constraints. It is adequate but leaves room for improvement.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description adds meaningful context for each parameter: network is explained with an example, pool_address as contract address, and include as comma-separated attributes. This adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it queries details for a specific pool on a network, using a specific verb and resource. It distinguishes itself from sibling tools that list pools or get trending pools, as it targets a single pool by address.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives like search_pools or get_top_pools. The description does not mention prerequisites or contexts where this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_supported_dexes_by_networkA

Query all supported DEXes for a specific network on GeckoTerminal and return a formatted table.

Args:
    network: The network identifier (default: "eth" for Ethereum)
    page: Page number for pagination (default: 1)

Returns:
    Formatted table as a string with columns: id, name

ParametersJSON Schema

Name	Required	Description	Default
`network`	No		eth
`page`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It explains the return format (formatted table with columns id, name) but does not disclose rate limits, authentication needs, or side effects. It is assumed read-only but not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, front-loaded with purpose, and structured with Args and Returns sections. It contains no redundant information, though default values are repeated from the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (two parameters) and existence of an output schema, the description covers key aspects: purpose, parameters, and return format. However, it lacks usage guidance and behavioral context, which for a query tool is acceptable but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates by explaining the network identifier (default 'eth') and page for pagination (default 1). It adds meaning beyond the schema but could list valid network identifiers or pagination limits.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it queries all supported DEXes for a specific network and returns a formatted table. The verb 'Query' and resource 'supported DEXes for a specific network' are precise, and it distinguishes from sibling tools like get_new_pools or get_pool_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit when-to-use or alternatives, but the context of sibling tools implies its purpose. It lacks exclusions or guidance on when not to use this tool compared to others like get_top_pools_by_dex.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_supported_networksA

Query all supported networks on GeckoTerminal and return a formatted table.

Args:
    page: Page number for pagination (default: 1)

Returns:
    Formatted table as a string with columns: id, name

ParametersJSON Schema

Name	Required	Description	Default
`page`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavior. It discloses pagination and return format (formatted string with columns), but lacks details on error handling, rate limits, or empty results. Adequate for a simple read query.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences plus an Args section, no fluff. Purpose and parameter are front-loaded, making it efficient for an AI agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional param, output schema exists), the description covers the key points: what it returns (formatted table with columns) and pagination. It could mention page size or total pages, but overall it's sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates. It explains the 'page' parameter as 'Page number for pagination (default: 1),' adding clear semantic meaning beyond the schema's type and default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Query all supported networks on GeckoTerminal and return a formatted table.' This is a specific verb-resource pair that distinguishes from sibling tools like get_supported_dexes_by_network, which focuses on exchanges by network.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: query all networks with optional pagination. It does not explicitly exclude other tools or state when-not, but the purpose is straightforward and distinct from siblings, so the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_top_pools_by_dexA

Query top pools for a specific network and DEX on GeckoTerminal and return a formatted table.

Args:
    network: The network identifier (default: "eth" for Ethereum)
    dex: The DEX identifier (default: "sushiswap")
    page: Page number for pagination (default: 1)
    sort: Sort pools by field (options: "h24_tx_count_desc", "h24_volume_usd_desc"; default: "h24_tx_count_desc")
    include: Comma-separated attributes to include (e.g., "base_token,quote_token,dex"; default: "base_token,quote_token,dex")

Returns:
    Formatted table as a string with columns: dex, name, base_price_in_quote, reserve_usd, volume_usd_24h, address

ParametersJSON Schema

Name	Required	Default
`network`	No	eth
`dex`	No	sushiswap
`page`	No
`sort`	No	h24_tx_count_desc
`include`	No	base_token,quote_token,dex

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It mentions the return format (formatted table with columns) but does not disclose other behavioral traits such as read-only nature, rate limits, or error conditions. The description adds minimal transparency beyond what is obvious from the name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, with a single purpose sentence followed by a clear Args list. Every sentence adds value; no redundancy or wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, an output schema, and no annotations, the description covers purpose, parameters, and return format adequately. It lacks details on error handling or data freshness, but for a straightforward query tool, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description's Args block explains each parameter fully, including defaults and allowed values for sort. This adds significant meaning that the schema lacks, enabling the agent to understand parameter semantics effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: querying top pools for a specific network and DEX on GeckoTerminal and returning a formatted table. It includes default values for network and DEX, and the phrase 'for a specific network and DEX' distinguishes it from siblings like get_top_pools_by_network.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when network and DEX are known but does not explicitly state when to use this tool versus alternatives like get_top_pools_by_network or get_trending_pools. No exclusions or alternative suggestions are provided, leaving guidance mostly implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_top_pools_by_networkA

Query top pools for a specific network on GeckoTerminal and return a formatted table.

Args:
    network: The network identifier (default: "eth" for Ethereum)
    page: Page number for pagination (default: 1)
    sort: Sort pools by field (options: "h24_tx_count_desc", "h24_volume_usd_desc"; default: "h24_tx_count_desc")
    include: Comma-separated attributes to include (e.g., "base_token,quote_token,dex"; default: "base_token,quote_token,dex")

Returns:
    Formatted table as a string with columns: dex, name, base_price_in_quote, reserve_usd, volume_usd_24h, address

ParametersJSON Schema

Name	Required	Default
`network`	No	eth
`page`	No
`sort`	No	h24_tx_count_desc
`include`	No	base_token,quote_token,dex

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It describes the return format and lists columns, but does not disclose whether the tool is read-only, requires authentication, or has rate limits. As a query tool, basic safety is inferred but not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: a single-sentence purpose followed by an Arg list and return specification. Every sentence adds value, and the structure is clear and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has four optional parameters and no output schema beyond the description, but the description specifies the return columns and explains each parameter. Given the simple query nature, the description is complete for an agent to understand and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully explains each parameter: network, page, sort, include. It provides defaults and acceptable options for sort and include, adding significant meaning beyond the schema's names and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Query top pools for a specific network on GeckoTerminal and return a formatted table.' This specifies the verb (query), resource (top pools), and scope (by network), effectively distinguishing it from siblings like get_top_pools_by_dex or get_trending_pools_by_network.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by stating it queries top pools for a network, but it does not explicitly suggest when to use this tool versus alternatives like get_top_pools_by_dex or get_new_pools_by_network. No when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_trending_poolsA

Query all trending pools across all networks on GeckoTerminal and return a formatted table.

Args:
    page: Page number for pagination (default: 1)
    duration: Duration to sort trending list by (options: "5m", "1h", "6h", "24h"; default: "24h")
    include: Comma-separated attributes to include (e.g., "base_token,quote_token,dex,network")

Returns:
    Formatted table as a string with columns: dex, network, name, base_price_in_quote, reserve_usd, volume_usd_24h, address

ParametersJSON Schema

Name	Required	Default
`page`	No
`duration`	No	24h
`include`	No	base_token,quote_token,dex,network

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses the return format (formatted table with specific columns) and parameter options with defaults. It implies a read-only operation but does not explicitly state non-mutation, error handling, or rate limits. Still, it offers sufficient behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a clear purpose sentence followed by parameter details. It is slightly verbose with a docstring-like format but remains concise and front-loaded. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, parameters, and return format adequately. It lacks cross-references to sibling tools or discussion of edge cases, but given the tool's simplicity and the presence of an output schema (described in text), it is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully explains each parameter: page (default 1), duration (options: 5m,1h,6h,24h, default 24h), include (comma-separated attributes with examples). It also describes the output. This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Query all trending pools across all networks on GeckoTerminal and return a formatted table,' which clearly specifies the verb (query), resource (trending pools), and scope (all networks). This distinguishes it from sibling tools like get_trending_pools_by_network or get_new_pools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for trending pools across all networks but does not explicitly state when to use this tool over alternatives or when not to use it. For example, it does not mention get_trending_pools_by_network for network-specific queries. Basic guidance is implied but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_trending_pools_by_networkB

Query trending pools for a specific network on GeckoTerminal and return a formatted table.

Args:
    network: The network identifier (default: "eth" for Ethereum)
    page: Page number for pagination (default: 1)
    duration: Duration to sort trending list by (options: "5m", "1h", "6h", "24h"; default: "24h")
    include: Comma-separated attributes to include (e.g., "base_token,quote_token,dex"; default: "base_token,quote_token,dex")

Returns:
    Formatted table as a string with columns: dex, name, base_price_in_quote, reserve_usd, volume_usd_24h, address

ParametersJSON Schema

Name	Required	Default
`network`	No	eth
`page`	No
`duration`	No	24h
`include`	No	base_token,quote_token,dex

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden. It explains parameters, defaults, and return format, which is adequate for a read-only query tool. However, it does not mention rate limits, authentication needs, or error handling, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with Args and Returns sections, front-loaded with the main purpose. It is concise without unnecessary verbosity, though the parameter descriptions could be slightly tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 optional parameters, no output schema provided but described), the description covers the necessary details for an agent to use it correctly. It lists return columns and parameter defaults, making it fairly complete despite missing error context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant value beyond the input schema, which has 0% description coverage. It explains each parameter's purpose, defaults, and lists duration options. The 'include' parameter could be more explicit about valid attributes, but overall it compensates well for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it queries trending pools for a specific network and returns a formatted table. The verb 'query' and resource 'trending pools' are specific. However, it does not explicitly differentiate from the sibling 'get_trending_pools' which likely covers all networks, leaving some ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'get_trending_pools' or 'get_top_pools_by_network'. It does not state prerequisites or when not to use it. The context is implied but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_poolsA

Search for pools on a specific network on GeckoTerminal and return a formatted table.

Args:
    query: Search query (default: "weth")
    network: The network identifier (default: "eth" for Ethereum)
    page: Page number for pagination (default: 1)
    include: Comma-separated attributes to include (e.g., "base_token,quote_token,dex"; default: "base_token,quote_token,dex")

Returns:
    Formatted table as a string with columns: dex, name, base_price_in_quote, reserve_usd, volume_usd_24h, address

ParametersJSON Schema

Name	Required	Default
`query`	No	weth
`network`	No	eth
`page`	No
`include`	No	base_token,quote_token,dex

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions returning a formatted table, implying a read operation, but does not explicitly state read-only behavior, rate limits, or authentication needs. The description adds some value beyond the schema but lacks rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a single sentence stating the purpose, followed by a clear Args/Returns section. Every sentence is necessary, and the purpose is front-loaded. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's 4 parameters, sibling tools, and the existence of an output schema, the description is complete. It covers the search functionality, pagination (page parameter), and return format (columns listed). The output schema renders further detail unnecessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the tool description includes a docstring that explains each parameter (e.g., 'Search query (default: "weth")'), adding meaning beyond the bare schema. This compensates for the lack of schema descriptions, though not all parameters are extensively detailed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for pools on a specific network and returns a formatted table. The verb 'search' and resource 'pools' are specific, and the tool is distinguished from siblings like get_new_pools or get_trending_pools by focusing on search with query parameters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context by listing parameters with defaults, but does not explicitly state when to use this tool vs alternatives like get_new_pools. However, the name and purpose imply it is for searching, which is a distinct use case among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

10 tool updatesv0.1.0May 26, 2026
- First observedget_new_pools
- First observedget_new_pools_by_network
- First observedget_pool_details
- First observedget_supported_dexes_by_network
- First observedget_supported_networks
- First observedget_top_pools_by_dex
- First observedget_top_pools_by_network
- First observedget_trending_pools
- First observedget_trending_pools_by_network
- First observedsearch_pools

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Scored 2026-05-26 08:15 across 10 tools

Disambiguation5/5

Every tool has a distinct and clear purpose: new pools, trending pools, top pools, pool details, supported entities, and search. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names consistently use the 'get' verb followed by a descriptive noun phrase in snake_case, forming a predictable pattern (e.g., get_new_pools, get_trending_pools_by_network).

Tool Count5/5

With 10 tools, the server is well-scoped for its purpose—providing comprehensive read access to DEX pool data without being overwhelming or incomplete.

Completeness4/5

The tool set covers the core use cases: fetching new, trending, top, and searched pools, plus details and supported networks/DEXes. A minor gap is the lack of a 'get_top_pools' across all networks, but agents can still achieve this by iterating over networks.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

crypto-defi-mcpOAuth
com.thenextgennexus
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Cryptocurrency Finance Blockchain
2
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
Hive Capital A
io.github.srotzin
HiveCapital MCP Server — autonomous investment layer for AI agents
Finance Autonomous Agents Blockchain
2

Related MCP Servers

uniswap-trader-mcp
Blockchain Web3 & Decentralized Tech
kukapay
A
license
Not graded
quality
F
maintenance
An MCP server for AI agents to automate token swaps on Uniswap DEX across multiple blockchains.
Updated a year ago (2025-05-07 17:23 UTC)
8
38
MIT
Armor Crypto MCPofficial
Blockchain Cryptocurrency Web3 & Decentralized Tech
armorwallet
A
license
C
quality
C
maintenance
An MCP server providing unified access to blockchain operations, bridging, swapping, and crypto trading strategies for AI agents.
Updated a year ago (2025-07-29 15:53 UTC)
37
179
GPL 3.0
liquidity-pools-mcp
Blockchain Web3 & Decentralized Tech
kukapay
A
license
A
quality
D
maintenance
An MCP server that tracks and analyzes DEX liquidity pools to power intelligent DeFi agents and automated strategies.
Updated a year ago (2025-06-09 08:26 UTC)
1
2
MIT
dex-kline-mcp
Blockchain Web3 & Decentralized Tech Vector Databases
kukapay
A
license
A
quality
D
maintenance
An MCP server that streams K-line (candlestick) data from decentralized exchanges (DEXs) to power your AI agents and workflows.
Updated a year ago (2025-07-02 16:57 UTC)
1
4
MIT

DEX Pools MCP

Features

Prerequisites

Installation

Usage

Available Tools

Examples

1. get_supported_networks

2. get_supported_dexes_by_network

3. get_new_pools

4. get_new_pools_by_network

5. get_trending_pools

6. get_trending_pools_by_network

7. get_top_pools_by_network

8. get_top_pools_by_dex

9. search_pools

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Armor Crypto MCPofficial

1. `get_supported_networks`

2. `get_supported_dexes_by_network`

3. `get_new_pools`

4. `get_new_pools_by_network`

5. `get_trending_pools`

6. `get_trending_pools_by_network`

7. `get_top_pools_by_network`

8. `get_top_pools_by_dex`

9. `search_pools`