Skip to main content
Glama

dexscreenertokeninfoagent_search_pairs

Search for decentralized exchange trading pairs by token name, symbol, or address. Retrieve price, volume, liquidity, and exchange availability across major DEXs and blockchains via DexScreener data.

Instructions

Search for trading pairs on decentralized exchanges by token name, symbol, or address. This tool helps you find specific trading pairs across multiple DEXs and blockchains. It returns information about the pairs including price, volume, liquidity, and the exchanges where they're available. Data comes from DexScreener and covers major DEXs on most blockchains. The search results may be incomplete if the token is not traded on any of the supported chains.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
search_termYesSearch term (token name, symbol, or address)

Implementation Reference

  • DexScreenerTokenInfoAgent is explicitly listed in the default supported agents, enabling registration of its tools such as dexscreenertokeninfoagent_search_pairs.
    # Default supported agents
    DEFAULT_AGENTS = [
        "CoinGeckoTokenInfoAgent",
        "DexScreenerTokenInfoAgent",
        "ElfaTwitterIntelligenceAgent",
        "ExaSearchAgent",
        "TwitterInfoAgent",
        "AIXBTProjectInfoAgent",
        "EtherscanAgent",
        "EvmTokenInfoAgent",
        "FundingRateAgent",
        "UnifaiTokenAnalysisAgent",
        "YahooFinanceAgent",
        "ZerionWalletAnalysisAgent"
    ]
  • Dynamic tool registration from agent metadata: constructs tool_id as lowercase(agent_id)_tool_name, matching 'dexscreenertokeninfoagent_search_pairs' for DexScreenerTokenInfoAgent's 'search_pairs' tool; stores schema, description, etc. in registry.
        for tool in agent_data.get("tools", []):
            if tool.get("type") == "function":
                function_data = tool.get("function", {})
                tool_name = function_data.get("name")
    
                if not tool_name:
                    continue
    
                # Create a unique tool ID
                tool_id = f"{agent_id.lower()}_{tool_name}"
    
                # Get parameters or create default schema
                parameters = function_data.get("parameters", {})
                if not parameters:
                    parameters = {
                        "type": "object",
                        "properties": {},
                        "required": [],
                    }
    
                # Store tool info
                tool_registry[tool_id] = {
                    "agent_id": agent_id,
                    "tool_name": tool_name,
                    "description": function_data.get("description", ""),
                    "parameters": parameters,
                }
    
    # Log which agents contributed tools
  • Core execution handler: takes agent_id and tool_name (parsed from tool_id), sends POST to Mesh API /mesh_request with tool and arguments, returns result. This implements the logic for dexscreenertokeninfoagent_search_pairs.
    async def execute_tool(
        self, agent_id: str, tool_name: str, tool_arguments: Dict[str, Any]
    ) -> Dict[str, Any]:
        """Execute a tool on a mesh agent.
    
        Args:
            agent_id: ID of the agent to execute the tool on
            tool_name: Name of the tool to execute
            tool_arguments: Arguments to pass to the tool
    
        Returns:
            Tool execution result
    
        Raises:
            ToolExecutionError: If there's an error executing the tool
        """
        request_data = {
            "agent_id": agent_id,
            "input": {"tool": tool_name, "tool_arguments": tool_arguments},
        }
    
        # Add API key if available
        if Config.HEURIST_API_KEY:
            request_data["api_key"] = Config.HEURIST_API_KEY
    
        try:
            result = await call_mesh_api(
                "mesh_request", method="POST", json=request_data
            )
            return result.get("data", result)  # Prefer the 'data' field if it exists
        except MeshApiError as e:
            # Re-raise API errors with clearer context
            raise ToolExecutionError(str(e)) from e
        except Exception as e:
            logger.error(f"Error calling {agent_id} tool {tool_name}: {e}")
            raise ToolExecutionError(
                f"Failed to call {agent_id} tool {tool_name}: {str(e)}"
            ) from e
  • MCP call_tool handler: looks up tool_info from registry by name (e.g. dexscreenertokeninfoagent_search_pairs), extracts agent_id/tool_name, calls execute_tool with arguments, returns result as TextContent.
    @app.call_tool()
    async def call_tool(name: str, arguments: dict) -> List[types.TextContent]:
        """Call the specified tool with the given arguments."""
        try:
            if name not in self.tool_registry:
                raise ValueError(f"Unknown tool: {name}")
    
            tool_info = self.tool_registry[name]
            result = await self.execute_tool(
                agent_id=tool_info["agent_id"],
                tool_name=tool_info["tool_name"],
                tool_arguments=arguments,
            )
    
            # Convert result to TextContent
            return [types.TextContent(type="text", text=str(result))]
        except Exception as e:
            logger.error(f"Error calling tool {name}: {e}")
            raise ValueError(f"Failed to call tool {name}: {str(e)}") from e
  • MCP list_tools exposes the schema (inputSchema) from remote agent metadata for each registered tool, including dexscreenertokeninfoagent_search_pairs.
    @app.list_tools()
    async def list_tools() -> List[types.Tool]:
        """List all available tools."""
        return [
            types.Tool(
                name=tool_id,
                description=tool_info["description"],
                inputSchema=tool_info["parameters"],
            )
            for tool_id, tool_info in self.tool_registry.items()
        ]
Behavior4/5

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 describes key traits: the data source ('DexScreener'), coverage ('major DEXs on most blockchains'), and limitations ('search results may be incomplete if the token is not traded on any of the supported chains'). It also hints at the scope ('covers multiple DEXs and blockchains') and output content. However, it omits details like rate limits, error handling, or pagination, which would be beneficial 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, with the first sentence stating the core purpose and the following sentences adding essential context without redundancy. Each sentence earns its place by covering search functionality, returns, data source, and limitations efficiently. There is no wasted text, making it easy for an agent to parse quickly.

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 (search across DEXs/blockchains), no annotations, and no output schema, the description does a solid job by explaining the purpose, data source, coverage, and limitations. It adequately compensates for the lack of structured fields, though it could benefit from more details on output format or error cases. For a search tool with one parameter, it provides sufficient context for effective use.

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%, with the parameter 'search_term' well-documented in the schema as 'Search term (token name, symbol, or address)'. The description adds minimal value beyond this, only reiterating that search is by 'token name, symbol, or address' without providing additional syntax, format examples, or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.

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 with specific verbs ('Search for trading pairs') and resources ('decentralized exchanges', 'trading pairs'), distinguishing it from siblings like 'get_specific_pair_info' or 'get_token_pairs' by emphasizing search functionality across multiple DEXs and blockchains. It explicitly identifies what it searches by ('token name, symbol, or address') and what it returns ('information about the pairs including price, volume, liquidity, and exchanges').

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 context for when to use this tool: to find trading pairs by token identifiers across DEXs and blockchains. It implicitly distinguishes from siblings like 'get_specific_pair_info' (which likely retrieves details for a known pair) and 'get_token_pairs' (which might list all pairs for a token without search). However, it lacks explicit when-not-to-use guidance or named alternatives, such as when to prefer sibling tools for non-search scenarios.

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

Related 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/heurist-network/heurist-mesh-mcp-server'

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