Skip to main content
Glama

get_multiple_token_balances

Retrieve token balances and their USD values for a specified wallet address using SailFish as the price oracle. Supports multiple token contract addresses for efficient balance tracking.

Instructions

Get multiple token balances for a wallet address with USD values using SailFish as price oracle

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenAddressesYesList of token contract addresses
walletAddressYesWallet address to check

Implementation Reference

  • Core handler function that implements the tool logic: fetches balances for multiple ERC20 tokens using getTokenBalance helper, handles individual token errors gracefully, returns array of balance info including metadata and optional USD value from SailFish subgraph.
    export async function getMultipleTokenBalances(
      tokenAddresses: string[], 
      walletAddress: string
    ): Promise<Array<{ 
      tokenAddress: string,
      balance: string, 
      decimals: number, 
      symbol: string, 
      name: string, 
      formattedBalance: string,
      usdValue?: string
    }>> {
      try {
        const results = await Promise.all(
          tokenAddresses.map(async (tokenAddress) => {
            try {
              const tokenBalance = await getTokenBalance(tokenAddress, walletAddress);
              return {
                tokenAddress,
                ...tokenBalance
              };
            } catch (error) {
              console.error(`Error fetching balance for token ${tokenAddress}:`, error);
              return {
                tokenAddress,
                balance: '0',
                decimals: 18,
                symbol: 'UNKNOWN',
                name: 'Unknown Token',
                formattedBalance: '0'
              };
            }
          })
        );
        
        return results;
      } catch (error) {
        console.error('Error fetching multiple token balances:', error);
        throw error;
      }
    }
  • src/index.ts:332-351 (registration)
    Tool registration in ListToolsRequestHandler: defines the tool name, description, and input schema for validation.
      name: 'get_multiple_token_balances',
      description: 'Get multiple token balances for a wallet address with USD values using SailFish as price oracle',
      inputSchema: {
        type: 'object',
        properties: {
          tokenAddresses: {
            type: 'array',
            items: {
              type: 'string',
            },
            description: 'List of token contract addresses',
          },
          walletAddress: {
            type: 'string',
            description: 'Wallet address to check',
          },
        },
        required: ['tokenAddresses', 'walletAddress'],
      },
    },
  • MCP tool dispatch handler in CallToolRequestHandler: validates input params and delegates to blockchain.getMultipleTokenBalances, formats response as MCP content.
    case 'get_multiple_token_balances': {
      if (!args.tokenAddresses || !Array.isArray(args.tokenAddresses)) {
        throw new McpError(ErrorCode.InvalidParams, 'Token addresses array is required');
      }
      
      if (!args.walletAddress || typeof args.walletAddress !== 'string') {
        throw new McpError(ErrorCode.InvalidParams, 'Wallet address is required');
      }
      
      const balances = await blockchain.getMultipleTokenBalances(args.tokenAddresses, args.walletAddress);
      
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(balances, null, 2),
          },
        ],
      };
  • Helper function used by getMultipleTokenBalances to fetch individual token balance, metadata, formatted amount, and USD value via SailFish subgraph.
    export async function getTokenBalance(
      tokenAddress: string, 
      walletAddress: string
    ): Promise<{ 
      balance: string, 
      decimals: number, 
      symbol: string, 
      name: string, 
      formattedBalance: string,
      usdValue?: string
    }> {
      try {
        const provider = getProvider();
        const tokenContract = new ethers.Contract(tokenAddress, ERC20_ABI, provider);
        
        // Get token details
        const [balance, decimals, symbol, name] = await Promise.all([
          tokenContract.balanceOf(walletAddress),
          tokenContract.decimals(),
          tokenContract.symbol(),
          tokenContract.name()
        ]);
        
        // Convert BigInt to string and number
        const balanceStr = bigIntToString(balance);
        const decimalsNum = Number(decimals);
        
        const formattedBalance = ethers.formatUnits(balance, decimalsNum);
        
        // Try to get USD value from SailFish
        let usdValue: string | undefined;
        try {
          const tokenPrice = await subgraph.getTokenPrice(tokenAddress);
          if (tokenPrice) {
            const valueInUsd = parseFloat(formattedBalance) * parseFloat(tokenPrice);
            usdValue = valueInUsd.toString();
          }
        } catch (error) {
          console.error('Error fetching token price:', error);
          // Continue without USD value
        }
        
        return {
          balance: balanceStr,
          decimals: decimalsNum,
          symbol: String(symbol),
          name: String(name),
          formattedBalance,
          usdValue
        };
      } catch (error) {
        console.error('Error fetching token balance:', error);
        throw error;
      }
    }
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 insight. It mentions using SailFish as a price oracle, which adds some context about price sourcing, but doesn't cover critical aspects like rate limits, error handling, response format, or whether this is a read-only operation (implied but not stated).

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 a single, efficient sentence that front-loads the core purpose. Every word earns its place by specifying the action, scope (multiple tokens), target (wallet address), key feature (USD values), and implementation detail (SailFish oracle) without redundancy.

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 no annotations and no output schema, the description is incomplete for a tool that likely returns complex financial data. It doesn't explain the return structure (e.g., balance arrays, USD conversions), error conditions, or dependencies like network requirements. For a 2-parameter tool with significant implied complexity, this is inadequate.

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 parameters are fully documented in the schema. The description adds no additional meaning about the parameters beyond what's in the schema (e.g., no examples, formatting details, or constraints). Baseline score of 3 is appropriate as the schema handles 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 action ('Get multiple token balances') and the resource ('for a wallet address'), and specifies the inclusion of USD values and price oracle. It distinguishes from sibling 'get_token_balance' by handling multiple tokens, but doesn't explicitly contrast with other balance tools like 'get_edu_balance' or 'get_nft_balance'.

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?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'get_token_balance' for single tokens, or how it relates to 'get_wallet_overview' for broader wallet analysis. The description lacks context about use cases or exclusions.

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/SailFish-Finance/educhain-ai-agent-kit'

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