Skip to main content
Glama
itsanishjain

Alchemy MCP Plugin

by itsanishjain
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

get_token_balances

Retrieve token balances for a specific wallet address using the Alchemy MCP Plugin. Filter results by token addresses to view specific asset holdings.

Instructions

Get token balances for a specific address

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYesThe wallet address to get token balances for
tokenAddressesNoList of token addresses to filter by

Implementation Reference

  • index.ts:59-59 (schema)
    TypeScript type definition for the input parameters of the get_token_balances tool.
    type GetTokenBalancesParams = { address: string; tokenAddresses?: string[] };
  • index.ts:131-140 (helper)
    Validation function to check if arguments match GetTokenBalancesParams type, used in the tool handler.
    const isValidGetTokenBalancesParams = (
  args: any
): args is GetTokenBalancesParams => {
  return (
    typeof args === "object" &&
    args !== null &&
    typeof args.address === "string" &&
    (args.tokenAddresses === undefined || Array.isArray(args.tokenAddresses))
  );
};
  • index.ts:703-722 (registration)
    Tool registration in the ListTools response, defining the name, description, and JSON input schema for MCP protocol.
      name: "get_token_balances",
  description: "Get token balances for a specific address",
  inputSchema: {
    type: "object",
    properties: {
      address: {
        type: "string",
        description: "The wallet address to get token balances for",
      },
      tokenAddresses: {
        type: "array",
        items: {
          type: "string",
        },
        description: "List of token addresses to filter by",
      },
    },
    required: ["address"],
  },
},

Tool Definition Quality

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it's likely non-destructive, but doesn't cover critical aspects like rate limits, authentication needs, error handling, or what happens if token addresses are invalid. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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 directly states the tool's function without any fluff. It's front-loaded with the core action and target, making it easy to parse. Every word earns its place, achieving maximum clarity with minimal length.

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 (querying token balances, which may involve API calls and data formatting), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values (e.g., balance amounts, token symbols), error cases, or network specifics (e.g., Ethereum mainnet). For a tool with no structured output or behavioral hints, more context is needed.

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 clear descriptions for both parameters in the input schema. The description adds no additional parameter semantics beyond implying the address is for token balances, which is already covered by the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even without extra param info in the description.

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 verb ('Get') and resource ('token balances') with a specific target ('for a specific address'), making the purpose unambiguous. It distinguishes from siblings like 'get_nfts_for_owner' or 'get_tokens_for_owner' by focusing on token balances rather than NFTs or token ownership details. However, it doesn't explicitly differentiate from all possible alternatives, keeping it at a 4 rather than a 5.

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 scenarios like checking balances for ERC-20 tokens, comparing with other tools like 'get_tokens_for_owner' (which might list tokens without balances), or prerequisites such as needing a valid wallet address. Without any usage context or exclusions, this is minimal guidance.

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

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/itsanishjain/alchemy-sdk-mcp'

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