DEX price/liquidity/volume data from DEX Screener API
Server has 6 tools with complete input schemas and basic descriptions. Naming follows verb_noun convention (get_, search_, latest_). However, descriptions are inconsistent in depth and lack actionable context for LLM selection. Parameter descriptions are minimal or absent (e.g., 'chain_id' lacks format guidance). No output schemas documented. Error handling is basic (404, 429, generic errors) with no recovery guidance. Missing parameter constraints (enums for chain values, limits for result counts). No tool annotations (readOnlyHint present via Risk field but not in MCP schema). Composition is sound, each tool has one responsibility. Overall: functional but below production baseline for agent-facing tools.
Pair detail (price USD/native, liquidity, 24h volume, 5m/1h/6h/24h tx counts).
All trading pairs for a token address on one chain.
Tokens being actively promoted on DEX Screener.
Newest token profiles created (cross-chain).
Free-text search across all DEX Screener chains for trading pairs matching a token name, symbol, or address. Returns up to 30 pairs with price USD, liquidity, 24h volume, and chain/DEX info.
Most-boosted tokens, optionally filtered to a chain / token.
No output schemas documented. LLMs cannot plan downstream calls or extract fields without knowing response structure (e.g., what fields does get_pair return? Is liquidity a number or object?).
Parameter 'chain' lacks enum constraint and format guidance. Description says 'Chain id, ethereum | solana | bsc | polygon | arbitrum | base | …' but uses examples instead of formal enum. LLMs may hallucinate invalid chain names.
Error handling provides no recovery guidance. Errors like 'DEX Screener: not found' or 'DEX Screener: rate-limit (HTTP 429)' do not tell the LLM what to do next (retry? search differently? ask user?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Descriptions for latest_token_profiles and latest_boosted_tokens are too generic (50 chars). 'Newest token profiles created (cross-chain)' lacks context on when to call this vs search_pairs, what data is returned, or typical use cases.
No result limits documented. search_pairs returns 'up to 30 pairs' but other tools do not state max result counts. Large unbounded responses risk context window exhaustion.