Skip to main content
Glama

coingeckotokeninfoagent_get_trending_coins

Retrieve a list of the top trending cryptocurrencies based on trading volume and social media mentions directly from CoinGecko. Optimize your crypto insights with real-time data.

Instructions

Get the current top trending cryptocurrencies on CoinGecko. This tool retrieves a list of the most popular cryptocurrencies based on trading volume and social media mentions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Handler function that executes the tool by looking up agent and tool name from registry and calling the Mesh API execute_tool method. This handles 'coingeckotokeninfoagent_get_trending_coins'.
    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
  • Code that dynamically registers tools by constructing tool_id as '{agent_id.lower()}_{tool_name}', loading schema from metadata, and storing in registry. This creates the 'coingeckotokeninfoagent_get_trending_coins' tool if configured.
    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
    
            # Check if this tool is enabled based on configuration
            if not self.is_tool_enabled(agent_id, tool_name):
                logger.debug(
                    f"Skipping tool {tool_name} for agent {agent_id} (not in config)"  # noqa: E501
                )
                tools_skipped += 1
                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,
            }
            tools_enabled += 1
            logger.debug(f"Enabled tool: {tool_id}")
  • Helper function that performs the actual API call to the Mesh sequencer to execute the agent's 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
  • In server.py variant, the CoinGeckoTokenInfoAgent is explicitly listed as a supported agent, enabling its tools like get_trending_coins to be dynamically registered as coingeckotokeninfoagent_get_trending_coins.
    DEFAULT_AGENTS = [
        "CoinGeckoTokenInfoAgent",
        "DexScreenerTokenInfoAgent",
        "ElfaTwitterIntelligenceAgent",
        "ExaSearchAgent",
        "TwitterInfoAgent",
        "AIXBTProjectInfoAgent",
        "EtherscanAgent",
        "EvmTokenInfoAgent",
        "FundingRateAgent",
        "UnifaiTokenAnalysisAgent",
        "YahooFinanceAgent",
        "ZerionWalletAnalysisAgent"
  • MCP list_tools handler that exposes the dynamically registered tools, including their schemas.
    @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()
        ]
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions the data sources (trading volume and social media mentions) but doesn't cover critical aspects like rate limits, authentication needs, data update frequency, error handling, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.

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 efficiently structured in two sentences: the first states the core purpose, the second elaborates on the data sources. Every word adds value with no redundancy or fluff. It's appropriately front-loaded with the main function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (trending data with multiple metrics), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the returned list contains (e.g., coin names, symbols, metrics), how many items are returned, whether it's paginated, or how 'trending' is calculated. For a data retrieval tool with no structured output documentation, more completeness is needed.

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

Parameters4/5

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 (empty schema). The description appropriately doesn't discuss parameters since none exist, which is correct. No additional parameter semantics are needed, so it meets the baseline for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 ('Get', 'retrieves') and resources ('top trending cryptocurrencies on CoinGecko', 'list of the most popular cryptocurrencies'). It distinguishes itself from siblings like 'get_token_info' or 'get_top_token_holders' by focusing on trending coins based on volume and social metrics. However, it doesn't explicitly differentiate from 'get_trending_pools' (which might be for DeFi pools rather than coins).

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

Usage Guidelines2/5

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 when to choose this over 'get_token_info' for specific token details, 'get_top_token_holders' for holder data, or 'get_trending_pools' for trending pools. There's also no context about prerequisites, frequency limits, or data freshness.

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