Skip to main content
Glama

coingeckotokeninfoagent_get_token_price_multi

Retrieve current prices and optional market data for multiple cryptocurrencies using CoinGecko IDs in a single API call. Supports target currencies, market cap, trading volume, price change, and precision settings for efficient data access.

Instructions

Fetch price data for multiple tokens at once using CoinGecko IDs. Efficiently retrieves current prices and optional market data for multiple cryptocurrencies in a single API call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsYesComma-separated CoinGecko IDs of the tokens to query
include_24hr_changeNoInclude 24hr price change percentage
include_24hr_volNoInclude 24hr trading volume data
include_last_updated_atNoInclude timestamp of when the data was last updated
include_market_capNoInclude market capitalization data
precisionNoDecimal precision for currency values (e.g., 'full' for maximum precision)
vs_currenciesYesComma-separated target currencies (e.g., usd,eur,btc)usd

Implementation Reference

  • DEFAULT_AGENTS list includes "CoinGeckoTokenInfoAgent", enabling its tools with names prefixed by "coingeckotokeninfoagent_"
    DEFAULT_AGENTS = [
        "CoinGeckoTokenInfoAgent",
        "DexScreenerTokenInfoAgent",
        "ElfaTwitterIntelligenceAgent",
        "ExaSearchAgent",
        "TwitterInfoAgent",
        "AIXBTProjectInfoAgent",
        "EtherscanAgent",
        "EvmTokenInfoAgent",
        "FundingRateAgent",
        "UnifaiTokenAnalysisAgent",
        "YahooFinanceAgent",
        "ZerionWalletAnalysisAgent"
    ]
  • Dynamically registers each agent tool as an MCP tool with ID '{agent_id.lower()}_{tool_name}', e.g. 'coingeckotokeninfoagent_get_token_price_multi'
        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
  • MCP handler for calling the tool: parses name to get agent/tool, invokes execute_tool which proxies to Mesh API.
    @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
  • Helper that sends tool call to Mesh API endpoint /mesh_request with agent_id and tool details.
    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
  • Registers tool schemas dynamically from metadata parameters.
    @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()
        ]
Behavior3/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 mentions the tool 'efficiently retrieves' data in a 'single API call,' which hints at performance benefits. However, it lacks details on rate limits, error handling, authentication needs, or data freshness guarantees. The description doesn't contradict annotations (none exist), but it's insufficient for a mutation-free read operation with external API dependencies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is concise and front-loaded, with two sentences that efficiently convey the core functionality. The first sentence states the purpose clearly, and the second adds context about efficiency. There's no wasted verbiage, though it could be slightly more structured (e.g., bullet points for key features).

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

Completeness3/5

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

Given the tool's moderate complexity (7 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the 'what' (fetch price data for multiple tokens) but lacks details on 'how' (e.g., response format, error cases) and 'why' (explicit comparison to siblings). For a read-only tool with full schema coverage, it meets minimum viability but leaves gaps in behavioral context.

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%, so the schema fully documents all 7 parameters. The description adds minimal value beyond the schema, only implying that parameters control 'optional market data' without specifying which ones. It doesn't explain parameter interactions or provide examples (e.g., format of 'ids'). Baseline 3 is appropriate since the schema does the heavy lifting.

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: 'Fetch price data for multiple tokens at once using CoinGecko IDs.' It specifies the action (fetch), resource (price data), and scope (multiple tokens). However, it doesn't explicitly differentiate from sibling tools like 'coingeckotokeninfoagent_get_token_info' which might fetch single token data, leaving some ambiguity about when to choose this multi-token version.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by mentioning 'multiple tokens at once' and 'single API call,' suggesting efficiency for batch queries. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'coingeckotokeninfoagent_get_token_info' (likely for single tokens) or other price-fetching tools. 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.

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