DEX Pools MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
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.
Average 4/5 across 10 of 10 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dex-pools-mcp MCP server](https://glama.ai/mcp/servers/kukapay/dex-pools-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kukapay/dex-pools-mcp)

Score Badge

Copy to your README.md:

[![dex-pools-mcp MCP server](https://glama.ai/mcp/servers/kukapay/dex-pools-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kukapay/dex-pools-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kukapay/dex-pools-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server