search_pairsFree-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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| pairs | Yes | Matching pairs | |
| query | Yes | Query that was searched | |
| pair_count | Yes | Number of pairs returned |
Changes observed during successful MCP inspections.
Output schema / descriptionPrevious value: -"Search results across all chains"New value: +"Free-text pair search across all chains"Output schema / properties / pair_countAdded value: +{
+ "description": "Number of pairs returned",
+ "type": "number"
+}Output schema / properties / pairs / descriptionPrevious value: -"Up to 30 matching pairs"New value: +"Matching pairs"Output schema / properties / pairs / items / properties / baseToken / descriptionAdded value: +"Base token address/name/symbol"Output schema / properties / pairs / items / properties / fdvAdded value: +{
+ "description": "Fully diluted valuation",
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / pairs / items / properties / liquidity / descriptionAdded value: +"Liquidity in USD and both tokens"Output schema / properties / pairs / items / properties / marketCapAdded value: +{
+ "description": "Market capitalisation",
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / pairs / items / properties / priceNative / descriptionAdded value: +"Price in the quote token"Output schema / properties / pairs / items / properties / priceUsd / descriptionAdded value: +"Price in USD"Output schema / properties / pairs / items / properties / priceUsd / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / pairs / items / properties / quoteToken / descriptionAdded value: +"Quote token address/name/symbol"Output schema / properties / pairs / items / properties / txns / descriptionAdded value: +"Buy/sell counts over m5/h1/h6/h24"Output schema / properties / pairs / items / properties / volume / descriptionAdded value: +"Volume over m5/h1/h6/h24"Output schema / properties / queryAdded value: +{
+ "description": "Query that was searched",
+ "type": "string"
+}Output schema / properties / schemaVersionRemoved value: -{
- "description": "API schema version",
- "type": "string"
-}Output schema / requiredAdded value: +[
+ "query",
+ "pair_count",
+ "pairs"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive semantics. The description adds value beyond that by disclosing the return limit ('up to 30 pairs'), the exact output fields ('price USD, liquidity, 24h volume, and chain/DEX info'), and the search scope. It does not contradict 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 a single, dense sentence that front-loads the action and scope, then lists return fields. Every clause adds necessary information—no filler, tautology, or redundancy. It is efficient and well-structured.
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 one parameter, existing output schema, and annotations covering safety, the description covers all essential aspects: what the query is for, what results include, and the limit. It does not need to explain return formats since an output schema exists. No critical operational detail is missing.
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?
With 0% schema coverage for the single parameter 'query', the description fully compensates by defining it as 'Free-text search' that matches token names, symbols, or addresses. Examples in the schema (e.g., 'USDC ETH', 'SOL USDT solana') reinforce this. The description adds meaning beyond the bare parameter name.
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 uses a specific verb ('search'), a clear resource ('trading pairs'), and an explicit scope ('across all DEX Screener chains'). It also specifies what it matches ('token name, symbol, or address'), which distinguishes it from sibling tools like get_pair and get_token that are specific lookups rather than free-text search.
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?
It clearly communicates that this is a free-text search tool for pairs, implying it is for broad, exploratory queries. However, it does not explicitly mention when to use it instead of alternatives like get_pair or get_token, nor does it state exclusions. The context is evident but not stated as direct contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.