Skip to main content
Glama
coinpaprika

DexPaprika (CoinPaprika)

Official

getNetworkDexes

Retrieve available decentralized exchanges (DEXes) for a specific blockchain network. Use network IDs from getNetworks to identify supported networks and access DEX data.

Instructions

Get available DEXes on a specific network. First call getNetworks to see valid network IDs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
networkYesNetwork ID from getNetworks (e.g., "ethereum", "solana")
pageNoPage number for pagination
limitNoNumber of items per page (max 100)
sortNoSort orderdesc
orderByNoHow to order the returned data

Implementation Reference

  • The async handler function that constructs the API endpoint for fetching DEXes on a specific network and calls the shared fetchFromAPI helper.
    async ({ network, page, limit, sort, orderBy }) => {
      let endpoint = `/networks/${network}/dexes?page=${page}&limit=${limit}&sort=${sort}`;
      if (orderBy) {
        endpoint += `&order_by=${orderBy}`;
      }
      const data = await fetchFromAPI(endpoint);
      return formatMcpResponse(data);
    }
  • Zod input schema defining parameters for the getNetworkDexes tool: network (required), pagination and sorting options.
    {
      network: z.string().describe('Network ID from getNetworks (e.g., "ethereum", "solana")'),
      page: z.number().optional().default(0).describe('Page number for pagination'),
      limit: z.number().optional().default(10).describe('Number of items per page (max 100)'),
      sort: z.enum(['asc', 'desc']).optional().default('desc').describe('Sort order'),
      orderBy: z.enum(['pool']).optional().describe('How to order the returned data')
    },
  • src/index.js:83-101 (registration)
    Full server.tool registration call that defines the getNetworkDexes tool, including name, description, input schema, and handler function.
    server.tool(
      'getNetworkDexes',
      'Get available DEXes on a specific network. First call getNetworks to see valid network IDs.',
      {
        network: z.string().describe('Network ID from getNetworks (e.g., "ethereum", "solana")'),
        page: z.number().optional().default(0).describe('Page number for pagination'),
        limit: z.number().optional().default(10).describe('Number of items per page (max 100)'),
        sort: z.enum(['asc', 'desc']).optional().default('desc').describe('Sort order'),
        orderBy: z.enum(['pool']).optional().describe('How to order the returned data')
      },
      async ({ network, page, limit, sort, orderBy }) => {
        let endpoint = `/networks/${network}/dexes?page=${page}&limit=${limit}&sort=${sort}`;
        if (orderBy) {
          endpoint += `&order_by=${orderBy}`;
        }
        const data = await fetchFromAPI(endpoint);
        return formatMcpResponse(data);
      }
    );
  • Shared helper function to fetch data from DexPaprika API, handles errors like rate limits and deprecated endpoints, used by getNetworkDexes handler.
    async function fetchFromAPI(endpoint) {
      try {
        const response = await fetch(`${API_BASE_URL}${endpoint}`);
        if (!response.ok) {
          if (response.status === 410) {
            throw new Error(
              'This endpoint has been permanently removed. Please use network-specific endpoints instead. ' +
              'For example, use /networks/{network}/pools instead of /pools. ' +
              'Get available networks first using the getNetworks function.'
            );
          }
          if (response.status === 429) {
            throw new Error(
              'Rate limit exceeded. You have reached the maximum number of requests allowed for the free tier. ' +
              'To increase your rate limits and access additional features, please consider upgrading to a paid plan at https://docs.dexpaprika.com/'
            );
          }
          throw new Error(`API request failed with status ${response.status}`);
        }
        return await response.json();
      } catch (error) {
        console.error(`Error fetching from API: ${error.message}`);
        throw error;
      }
    }
  • Shared helper to format API response data into MCP-compatible text content format, used by getNetworkDexes handler.
    function formatMcpResponse(data) {
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(data)
          }
        ]
      };
    }
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 mentions the prerequisite of calling getNetworks first, which is useful behavioral context. However, it lacks details on rate limits, authentication needs, error handling, or return format, leaving gaps for a read operation with pagination.

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?

Two sentences with zero waste: the first states the purpose, the second provides essential usage guidance. It is front-loaded and appropriately sized, earning its place efficiently without redundancy.

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?

For a read tool with no annotations and no output schema, the description is minimal but covers purpose and prerequisite. It lacks details on return values, pagination behavior, or error cases, making it adequate but with clear gaps given the tool's complexity and parameter count.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional parameter semantics beyond implying network IDs come from getNetworks, which is already hinted in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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 specific action ('Get available DEXes') and resource ('on a specific network'), distinguishing it from siblings like getNetworks (which lists networks) and getDexPools (which focuses on pools). It provides precise scope by mentioning network IDs from getNetworks.

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

Usage Guidelines5/5

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

It explicitly states when to use this tool ('First call getNetworks to see valid network IDs'), providing a prerequisite and distinguishing it from getNetworks. This gives clear context for usage without alternatives needed, as siblings serve different purposes (e.g., getDexPools for pools, not DEXes).

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

Install Server

Other Tools

Latest Blog Posts

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/coinpaprika/dexpaprika-mcp'

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