Provides access to Ethereum DEX data including token prices, liquidity pools, trading volumes, and transaction history across decentralized exchanges like Uniswap
Allows querying Fantom network DEX data for token analysis, liquidity pool monitoring, and trading volume statistics across supported decentralized exchanges
Enables retrieval of Solana blockchain DEX analytics including token metrics, pool data, OHLCV price data, and trading activity from decentralized exchanges like Raydium
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DexPaprika MCP Server show me the top 5 pools on Ethereum by volume"
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.
A Model Context Protocol (MCP) server that provides on-demand access to DexPaprika's cryptocurrency and DEX data API. Built specifically for AI assistants like Claude to programmatically fetch real-time token, pool, and DEX data with zero configuration.
# Install globally
npm install -g dexpaprika-mcp
# Start the server
dexpaprika-mcp
# Or run directly without installation
npx dexpaprika-mcpDexPaprika MCP connects Claude to live DEX data across multiple blockchains. No API keys required. Installation | Configuration | API Reference
Related MCP server: Crypto Indicators MCP Server
Breaking Change: The global /pools endpoint has been removed. If you're upgrading from v1.0.x, please see the Migration Guide below.
Token Analysis Tools: Track price movements, liquidity depth changes, and volume patterns
DEX Comparisons: Analyze fee structures, volume, and available pools across different DEXes
Liquidity Pool Analytics: Monitor TVL changes, impermanent loss calculations, and price impact assessments
Market Analysis: Cross-chain token comparisons, volume trends, and trading activity metrics
Portfolio Trackers: Real-time value tracking, historical performance analysis, yield opportunities
Technical Analysis: Perform advanced technical analysis using historical OHLCV data, including trend identification, pattern recognition, and indicator calculations
To install DexPaprika for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @coinpaprika/dexpaprika-mcp --client claude# Install globally (recommended for regular use)
npm install -g dexpaprika-mcp
# Verify installation
dexpaprika-mcp --version
# Start the server
dexpaprika-mcpThe server runs on port 8010 by default. You'll see MCP server is running at http://localhost:8010 when successfully started.
Watch our step-by-step tutorial on setting up and using the DexPaprika MCP server:
Add the following to your Claude Desktop configuration file:
macOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"dexpaprika": {
"command": "npx",
"args": ["dexpaprika-mcp"]
}
}
}After restarting Claude Desktop, the DexPaprika tools will be available to Claude automatically.
The global getTopPools function has been removed due to API deprecation.
Before (v1.0.x):
// This will no longer work
getTopPools({ page: 0, limit: 10, sort: 'desc', orderBy: 'volume_usd' })After (v1.1.0):
// Use network-specific queries instead
getNetworkPools({ network: 'ethereum', page: 0, limit: 10, sort: 'desc', orderBy: 'volume_usd' })
getNetworkPools({ network: 'solana', page: 0, limit: 10, sort: 'desc', orderBy: 'volume_usd' })
// To query multiple networks, call getNetworkPools for each network
// Or use the search function for cross-network searchesBetter Performance: Network-specific queries are faster and more efficient
More Relevant Results: Get pools that are actually relevant to your use case
Improved Scalability: Better suited for handling large amounts of data across networks
The MCP server exposes these specific endpoints Claude can access:
Function | Description | Example |
| Retrieves all supported blockchain networks and metadata |
|
| Lists DEXes available on a specific network |
|
Function | Description | Required Parameters | Example Usage |
| [PRIMARY] Gets top pools on a specific network |
| Get Solana's highest liquidity pools |
| Gets top pools for a specific DEX |
| List pools on Uniswap V3 |
| Gets detailed pool metrics |
| Complete metrics for USDC/ETH pool |
| Retrieves time-series price data for various analytical purposes (technical analysis, ML models, backtesting) |
| 7-day hourly candles for SOL/USDC |
| Lists recent transactions in a pool |
| Last 20 swaps in a specific pool |
Function | Description | Required Parameters | Output Fields |
| Gets comprehensive token data |
|
|
| Lists pools containing a token |
| Returns all pools with liquidity metrics |
| Finds tokens, pools, DEXes by name/id |
| Multi-entity search results |
// With Claude, get details about a specific token:
const solanaJupToken = await getTokenDetails({
network: "solana",
tokenAddress: "JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN"
});
// Find all pools for a specific token with volume sorting:
const jupiterPools = await getTokenPools({
network: "solana",
tokenAddress: "JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN",
orderBy: "volume_usd",
limit: 5
});
// Get top pools on Ethereum (v1.1.0 approach):
const ethereumPools = await getNetworkPools({
network: "ethereum",
orderBy: "volume_usd",
limit: 10
});
// Get historical price data for various analytical purposes (technical analysis, ML models, backtesting):
const ohlcvData = await getPoolOHLCV({
network: "ethereum",
poolAddress: "0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640", // ETH/USDC on Uniswap V3
start: "2023-01-01",
interval: "1d",
limit: 30
});When working with Claude, try these specific technical queries (updated for v1.1.0):
"Analyze the JUP token on Solana. Fetch price, volume, and top liquidity pools."
"Compare trading volume between Uniswap V3 and SushiSwap on Ethereum."
"Get the 7-day OHLCV data for SOL/USDC on Raydium and plot a price chart."
"Find the top 5 pools by liquidity on Fantom network and analyze their fee structures."
"Get recent transactions for the ETH/USDT pool on Uniswap and analyze buy vs sell pressure."
"Show me the top 10 pools on Ethereum by 24h volume using getNetworkPools."
"Search for all pools containing the ARB token and rank them by volume."
"Retrieve OHLCV data for BTC/USDT to analyze volatility patterns and build a price prediction model."
"First get all available networks, then show me the top pools on each major network."
Free Tier Limits: 60 requests per minute
Response Time: 100-500ms for most endpoints (network dependent)
Data Freshness: Pool and token data updated every 15-30s
Error Handling: 429 status codes indicate rate limiting
OHLCV Data Availability: Historical data typically available from token/pool creation date
Common Issues:
Rate limiting: If receiving 429 errors, reduce request frequency
Missing data: Some newer tokens/pools may have incomplete historical data
Timeout errors: Large data requests may take longer, consider pagination
Network errors: Check network connectivity, the service requires internet access
OHLCV limitations: Maximum range between start and end dates is 1 year; use pagination for longer timeframes
Migration Issues:
"getTopPools not found": This function has been removed. Use getNetworkPools instead with a specific network parameter
"410 Gone" errors: You're using a deprecated endpoint. Check the error message for guidance on the correct endpoint to use
# Clone the repository
git clone https://github.com/coinpaprika/dexpaprika-mcp.git
cd dexpaprika-mcp
# Install dependencies
npm install
# Run with auto-restart on code changes
npm run watch
# Build for production
npm run build
# Run tests
npm testSee CHANGELOG.md for detailed release notes and migration guides.
This project is licensed under the MIT License - see the LICENSE file for details.
DexPaprika - Comprehensive onchain analytics market data
CoinPaprika - Comprehensive cryptocurrency market data
Get pools from a specific DEX on a network. First use getNetworks, then getNetworkDexes to find valid DEX IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | Network ID from getNetworks (e.g., "ethereum", "solana") | |
| dex | Yes | DEX identifier from getNetworkDexes (e.g., "uniswap_v3") | |
| page | No | Page number for pagination | |
| limit | No | Number of items per page (max 100) | |
| sort | No | Sort order | desc |
| orderBy | No | Field to order by | volume_usd |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the prerequisite tools, it doesn't describe what 'Get pools' actually returns (e.g., pool metadata, liquidity data), whether there are rate limits, authentication requirements, or pagination behavior beyond what's in the schema. For a tool with 6 parameters and no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that both earn their place. The first sentence states the core purpose, and the second provides crucial usage guidance. There's no wasted verbiage or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is incomplete. While it provides good usage guidance, it lacks information about what the tool returns, error conditions, or behavioral characteristics. The agent would need to guess about the response format and operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal value beyond the schema by mentioning the prerequisite tools for network and dex parameters, but doesn't provide additional context about parameter interactions or usage patterns. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get pools') and resource ('from a specific DEX on a network'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like getNetworkPools or getTokenPools, which appear to serve similar pool-related functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'First use getNetworks, then getNetworkDexes to find valid DEX IDs.' This creates a clear prerequisite workflow and distinguishes it from other pool-related tools by emphasizing the DEX-specific filtering requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available DEXes on a specific network. First call getNetworks to see valid network IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | Network ID from getNetworks (e.g., "ethereum", "solana") | |
| page | No | Page number for pagination | |
| limit | No | Number of items per page |
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 requires a network ID from getNetworks, which is useful context. However, it doesn't describe behavioral traits like whether it's read-only, potential rate limits, error handling, or the format of returned DEX data. The description adds some value but lacks comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, and the second provides essential usage guidance. Every sentence earns its place with no wasted words, making it efficient and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, 1 required), no annotations, and no output schema, the description is somewhat complete but has gaps. It covers purpose and prerequisites but lacks details on return values, error cases, or behavioral constraints. It's adequate as a minimum viable description but could be more comprehensive for a tool with pagination and network dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (network, page, limit) with descriptions and defaults. The description adds no additional parameter semantics beyond what the schema provides, such as examples of DEX types or pagination behavior. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get available DEXes on a specific network.' It specifies the verb ('Get') and resource ('DEXes'), and distinguishes it from siblings like getNetworks (which provides network IDs) and getDexPools (which focuses on pools within DEXes). However, it doesn't explicitly contrast with all siblings, such as getNetworkPools, which might overlap in network focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'First call getNetworks to see valid network IDs.' This gives a prerequisite and distinguishes it from getNetworks. It implies when to use this tool (after obtaining network IDs) but doesn't explicitly state when not to use it or mention alternatives like getNetworkPools for pools instead of DEXes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PRIMARY POOL FUNCTION: Get top liquidity pools on a specific network. This is the MAIN way to get pool data - there is NO global pools function. Use this instead of any "getTopPools" or "getAllPools" concepts.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | Network ID from getNetworks (required) - e.g., "ethereum", "solana" | |
| page | No | Page number for pagination | |
| limit | No | Number of items per page (max 100) | |
| sort | No | Sort order | desc |
| orderBy | No | Field to order by | volume_usd |
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 this is for 'top liquidity pools' and the 'MAIN way to get pool data,' which gives some behavioral context about scope and importance. However, it doesn't disclose critical behavioral traits like rate limits, authentication requirements, error conditions, or what 'top' means (e.g., by volume, liquidity). The description adds value but leaves significant gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, with only two sentences that directly address purpose and usage guidelines. Every sentence earns its place by providing critical information without redundancy or fluff, making it efficient and well-structured for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is fairly complete for its core purpose and usage. It clearly states what the tool does and when to use it, which are key for an AI agent. However, it lacks details on behavioral aspects like rate limits or error handling, and without an output schema, it doesn't describe return values, leaving some gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain 'network' beyond being 'specific,' or clarify 'page'/'limit' usage). With high schema coverage, the baseline is 3, and the description doesn't compensate with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb ('Get') and resource ('top liquidity pools on a specific network'), making the purpose clear. It distinguishes this tool from sibling tools by emphasizing it's the 'MAIN way to get pool data' and explicitly mentions alternatives to avoid ('getTopPools' or 'getAllPools' concepts), providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by stating 'This is the MAIN way to get pool data - there is NO global pools function' and instructing to 'Use this instead of any "getTopPools" or "getAllPools" concepts.' This clearly indicates when to use this tool versus alternatives, including both positive direction (use this) and exclusions (not other concepts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
REQUIRED FIRST STEP: Get all supported blockchain networks. Always call this first to see available networks before using any network-specific functions. Returns network IDs like "ethereum", "solana", etc.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read operation (no destructive implications), provides context about the return format ('Returns network IDs like "ethereum", "solana", etc.'), and establishes its role as a prerequisite step. However, it doesn't mention potential limitations like rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and front-loaded: the first sentence establishes the core purpose, the second provides critical usage guidance, and the third clarifies the return format. Every sentence earns its place with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description provides excellent contextual completeness. It explains what the tool does, when to use it, and what it returns. The only minor gap is the lack of output schema, but the description compensates by describing the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and usage context, which adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('Get') and resource ('all supported blockchain networks'), and distinguishes it from siblings by explaining it's a prerequisite for network-specific functions. It provides explicit differentiation from tools like getNetworkDexes or getNetworkPools that require network IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions: 'REQUIRED FIRST STEP' and 'Always call this first to see available networks before using any network-specific functions.' It clearly indicates when to use this tool versus alternatives (network-specific functions) and establishes a clear prerequisite relationship.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific pool. Requires network ID from getNetworks and a pool address.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | Network ID from getNetworks (e.g., "ethereum", "solana") | |
| poolAddress | Yes | Pool address or identifier | |
| inversed | No | Whether to invert the price ratio |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions a requirement ('Requires network ID from getNetworks') but doesn't cover other behavioral aspects like whether this is a read-only operation, potential rate limits, error conditions, or what the detailed information includes. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first states the purpose, and the second provides usage context. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that retrieves 'detailed information'. It doesn't specify what details are included, the format of the response, or any behavioral constraints. However, the purpose and basic usage are clear, making it minimally viable but with notable gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'network ID from getNetworks' and 'pool address', which slightly reinforces the schema but doesn't provide additional semantics beyond it. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a specific pool', which is specific and actionable. However, it doesn't explicitly differentiate from siblings like getPoolOHLCV or getPoolTransactions, which also retrieve pool-related data but for different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Requires network ID from getNetworks', which implicitly guides usage by indicating a prerequisite tool. It doesn't explicitly mention when not to use this tool or name alternatives among siblings, but the context is sufficient for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical price data (OHLCV) for a pool - essential for price analysis, backtesting, and visualization. Requires network and pool address.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | Network ID from getNetworks (e.g., "ethereum", "solana") | |
| poolAddress | Yes | Pool address or identifier | |
| start | Yes | Start time for historical data (Unix timestamp, RFC3339 timestamp, or yyyy-mm-dd format) | |
| end | No | End time for historical data (max 1 year from start) | |
| limit | No | Number of data points to retrieve (max 366) - adjust for different analysis needs | |
| interval | No | Interval granularity: 1m, 5m, 10m, 15m, 30m, 1h, 6h, 12h, 24h | 24h |
| inversed | No | Whether to invert the price ratio for alternative pair perspective (e.g., ETH/USDC vs USDC/ETH) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the requirement for network and pool address, which is helpful context. However, it doesn't describe rate limits, authentication needs, error conditions, or what the return data structure looks like (though there's no output schema). The description adds some value but leaves significant behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief (two sentences) and front-loaded with the core purpose. The second sentence adds essential context about requirements. There's no wasted verbiage, though it could potentially be structured more clearly as separate sentences for purpose and requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description provides basic purpose and requirements but lacks details about return format, error handling, or behavioral constraints. The 100% schema coverage helps with parameters, but overall completeness is only adequate given the complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 7 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get historical price data'), resource ('for a pool'), and data format ('OHLCV'). It distinguishes this tool from siblings like getPoolDetails or getPoolTransactions by focusing specifically on price history rather than general pool information or transaction data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions use cases ('price analysis, backtesting, and visualization') which implies when to use this tool, but doesn't explicitly state when NOT to use it or name alternatives. It doesn't differentiate from potential sibling tools that might provide similar data in different formats or contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent transactions for a specific pool. Shows swaps, adds, removes. Requires network and pool address.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | Network ID from getNetworks (e.g., "ethereum", "solana") | |
| poolAddress | Yes | Pool address or identifier | |
| page | No | Page number for pagination (up to 100 pages) | |
| limit | No | Number of items per page (max 100) | |
| cursor | No | Transaction ID used for cursor-based pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the requirement for network and pool address but lacks details on permissions, rate limits, error conditions, or what 'recent' means (time window). It also doesn't describe the return format or pagination behavior beyond what's implied by parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) with zero wasted words. It front-loads the core purpose and efficiently lists transaction types and requirements. Every sentence earns its place by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (transaction data structure), how pagination works with page/limit versus cursor, or behavioral aspects like rate limits. The agent would lack sufficient context to use this tool effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal value beyond the schema by mentioning that network and pool address are required, but doesn't provide additional context about parameter interactions or usage nuances. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get recent transactions') and resource ('for a specific pool'), with specific transaction types enumerated ('shows swaps, adds, removes'). However, it doesn't explicitly differentiate from sibling tools like getPoolDetails or getPoolOHLCV, which also retrieve pool-related data but for different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'Requires network and pool address', which are mandatory parameters, but doesn't provide explicit guidance on when to use this tool versus alternatives like getPoolDetails (for pool metadata) or getPoolOHLCV (for price data). No exclusions or specific scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get high-level statistics about the DexPaprika ecosystem: total networks, DEXes, pools, and tokens available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves statistics but lacks behavioral details such as whether it's read-only (implied but not stated), data freshness, rate limits, authentication needs, or error handling. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get high-level statistics') and specifies the data returned. There is zero waste, and every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what data is returned but not the format (e.g., JSON structure, units) or behavioral aspects. For a read-only stats tool, this is minimally viable but could be more complete by addressing output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter information, focusing on the tool's purpose instead, which aligns with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('high-level statistics about the DexPaprika ecosystem'), specifying what data is returned (total networks, DEXes, pools, and tokens). It distinguishes from siblings by focusing on aggregated ecosystem stats rather than specific entities like networks, pools, or tokens, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like needing overview data versus detailed information, or compare to siblings like 'getNetworks' for network lists or 'search' for specific queries, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific token on a network. First use getNetworks to get valid network IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | Network ID from getNetworks (e.g., "ethereum", "solana") | |
| tokenAddress | Yes | Token address or identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the prerequisite of using getNetworks first, which adds useful context about dependencies. However, it doesn't describe what 'detailed information' includes, potential rate limits, error conditions, or authentication requirements, leaving significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, both of which earn their place. The first sentence states the core purpose, and the second provides essential usage guidance. There's no wasted language or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with full schema coverage but no annotations and no output schema, the description provides adequate basic context about what the tool does and a prerequisite. However, for a tool that presumably returns detailed token information, the description should ideally specify what kind of information is returned (metadata, pricing, supply, etc.) since there's no output schema to document this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions network IDs but doesn't provide additional context about token address formats or validation rules. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a specific token on a network', making the purpose understandable. However, it doesn't explicitly distinguish this tool from sibling tools like getTokenPools or getTokenMultiPrices, which likely provide different token-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to 'First use getNetworks to get valid network IDs', which is helpful context for proper usage. However, it doesn't specify when to use this tool versus alternatives like getTokenPools or getTokenMultiPrices, nor does it mention any exclusions or prerequisites beyond the network ID requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get liquidity pools containing a specific token on a network. Great for finding where a token is traded.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | Network ID from getNetworks (e.g., "ethereum", "solana") | |
| tokenAddress | Yes | Token address or identifier | |
| page | No | Page number for pagination | |
| limit | No | Number of items per page (max 100) | |
| sort | No | Sort order | desc |
| orderBy | No | Field to order by | volume_usd |
| reorder | No | If true, reorders the pool so that the specified token becomes the primary token for all metrics | |
| address | No | Filter pools that contain this additional token address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions the tool is 'great for finding where a token is traded,' which hints at a read-only lookup function, but doesn't explicitly state whether it's a read operation, what permissions are needed, or any rate limits. For a tool with 8 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the core purpose. Every sentence earns its place: the first states what the tool does, and the second provides usage context. There's zero wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and hints at usage but lacks behavioral details (e.g., pagination behavior, error cases, or response format). For a read-focused tool with rich schema documentation, it's passable but leaves room for improvement in contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain the 'reorder' parameter's effect or provide examples). With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get liquidity pools containing a specific token on a network.' It specifies the verb ('Get'), resource ('liquidity pools'), and scope ('containing a specific token on a network'). However, it doesn't explicitly differentiate from sibling tools like 'getNetworkPools' or 'getDexPools' beyond the token-specific focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context: 'Great for finding where a token is traded.' This suggests the tool is for discovering trading venues for a token. However, it doesn't explicitly state when to use this tool versus alternatives like 'getNetworkPools' (which might list all pools) or 'search' (which might have broader functionality). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across ALL networks for tokens, pools, and DEXes by name, symbol, or address. Good starting point when you don't know the specific network.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term (e.g., "uniswap", "bitcoin", or a token address) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the search scope and purpose, it doesn't describe important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, response format, or pagination behavior for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that each earn their place. The first sentence states the purpose and scope, while the second provides usage guidance. There's zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a simple single-parameter input schema, the description is adequate but has clear gaps. It explains what the tool does and when to use it, but doesn't address behavioral aspects like safety, performance, or response format that would be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'query' parameter with its description and type. The description adds marginal value by mentioning what can be searched ('name, symbol, or address') and providing examples, but doesn't add significant meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches across all networks for tokens, pools, and DEXes by name, symbol, or address. It specifies the verb ('search'), resources ('tokens, pools, and DEXes'), and scope ('across ALL networks'), but doesn't explicitly differentiate from siblings like getNetworkDexes or getNetworkPools that appear to be network-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Good starting point when you don't know the specific network.' This gives practical guidance, though it doesn't explicitly name alternatives or specify when not to use it (e.g., when you already know the network).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0getDexPools2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsegetNetworkDexes2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsegetNetworkPools2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsegetNetworks1 field changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"getPoolDetails2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsegetPoolOHLCV2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsegetPoolTransactions2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsegetStats1 field changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"getTokenDetails2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsegetTokenPools2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsesearch2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsegetDexPoolsgetNetworkDexesgetNetworkPoolsgetNetworksgetPoolDetailsgetPoolOHLCVgetPoolTransactionsgetStatsgetTokenDetailsgetTokenPoolssearchScored across 11 tools
Each tool has a clearly distinct purpose with no overlap. For example, getNetworkPools retrieves top pools on a network, while getDexPools targets pools from a specific DEX, and getPoolDetails provides detailed information for a single pool. The descriptions explicitly guide usage, preventing confusion.
All tool names follow a consistent verb_noun pattern with 'get' as the prefix (e.g., getNetworks, getPoolDetails, getTokenPools). The naming is uniform and predictable, making it easy for agents to understand the action and target resource.
With 11 tools, the server is well-scoped for its domain of blockchain DEX data analysis. Each tool serves a specific function, from network discovery to pool and token details, without redundancy. The count supports comprehensive coverage without being overwhelming.
The tool set provides complete coverage for exploring DEX data, including network discovery, DEX and pool listings, detailed views, historical data, transactions, and search. There are no obvious gaps; agents can navigate from high-level stats to granular details seamlessly.
Query real-time blockchain token data across EVM and Solana networks. Access token balances, transfers, prices, holders, NFT ownership, DEX swaps, and liquidity pools. Supports Ethereum, Base, Arbitrum, BSC, Polygon, Solana, and more.
Open API Marketplace for AI Agents. Crypto data tools with USDC payments on Base.
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
