Skip to main content
Glama
Sign In

Vike Data API

by io.vike
OverviewDiscussionsAdmin

Wallet Token Balances

wallet_token_balances
Read-onlyIdempotent

Current token balances for a wallet on Ethereum, BSC, Base and HyperEVM, read from the chain at request time. Returns per-holding (chain, symbol, balance, USD value, USD price). On base and hyperevm, symbol, name, balance and USD exist only for tokens we map and price (about 170 on base, about 50 on hyperevm). Any other token is listed, with its address and balance_raw and the rest null, only when min_usd=0 is passed: the default floor of $1 keeps priced tokens only. A non-zero native balance is always listed, with a USD value where a price exists; HyperCore (spot or perp accounts) is not included. Use when the user asks 'what tokens does this wallet hold' / 'current portfolio of X' — pair with wallet_label_provenance for institutional context.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "wallet_token_balances"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainsNoChains to scan: ethereum, bsc, base, hyperevm (default: all four). Any other chain is reported in chain_errors
addressYesWallet address (0x-prefixed)
min_usdNoFilter dust below this USD value (default 1.0)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: discloses that data is read from chain at request time, quantifies coverage per chain (~170 tokens priced on Base, ~50 on HyperEVM), explains the default $1 dust floor and how min_usd=0 unlocks unmapped tokens with null fields, guarantees native balances are always listed, and explicitly excludes HyperCore spot/perp accounts.

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?

Front-loads what is returned and where, then layers coverage caveats and the usage trigger. Dense but every clause carries a distinct constraint; the long middle sentence about mapping coverage is the only mild readability cost.

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

Completeness5/5

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

No output schema exists, and the description compensates by naming returned fields and explaining when fields are null. Combined with the coverage caveats and the HyperCore exclusion, an agent has everything needed to call it and interpret the result correctly.

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?

Schema coverage is 100%, so baseline is 3; the description adds real meaning by explaining the consequence of the min_usd default (priced tokens only) and what min_usd=0 unlocks, plus per-chain mapping limits that affect which 'chains' values are actually useful. It does not restate the address format, which the schema already covers.

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?

States a specific verb and resource ('Current token balances for a wallet'), enumerates the four supported chains, and enumerates the returned fields (chain, symbol, balance, USD value, USD price). It is clearly separable from siblings like token_holders (holders of a token) and wallet_summary (aggregate portfolio stats).

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?

Gives explicit trigger phrasing ('what tokens does this wallet hold' / 'current portfolio of X') and a pairing suggestion with wallet_label_provenance for institutional context. It does not name an adjacent alternative (e.g., wallet_summary for totals or token_screener for token-level data) or state exclusions, so 4 rather than 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Vike Data API toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources