Skip to main content
Glama
w3tech

Ankr Agent RPC

by w3tech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Account balance by chain

getAccountBalance
Read-only

Fetch an account's balance across multiple blockchains by 0x address or ENS name, ranked by USD value, with optional chain filters and dust summarization.

Instructions

Balance of an account across many blockchains, by 0x address or ENS name, via the Ankr Advanced API indexer. Assets are ranked by USD value descending and only the top 20 are listed by default (a real wallet can hold 1000+ assets, over half of them priced at $0); tune that with maxTokens/minUsd, or call getBalances for structured JSON. Anything the indexer PRICED at zero or below minUsd is summarised as a dust count instead of being listed. An asset with NO indexer price is not dust: it reads "USD value unknown" and ranks after every priced asset, so on a wallet holding more priced assets than maxTokens none appear here and the note says how many exist off-page. Unknown is not zero. An implausibly large raw balance (typical of scam tokens minting max-uint) is flagged and its balance is withheld; never add it to a total. Each line names the chain the asset is held on, which matters because omitting blockchains queries EVERY chain and interleaves the result across them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
minUsdNoOnly list assets worth at least this many USD; the rest are summarised as dust.
addressYesWallet address (0x...) or ENS name (*.eth)
maxTokensNoMax assets to list, sorted by USD value descending (default 20, max 100).
blockchainsNoChains to query; omit to query every chain

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover read-only/open-world safety. The description goes well beyond: dust summarisation, the distinction between 'unknown price' and zero, off-page counts when priced assets exceed maxTokens, and withholding of implausibly large scam-token balances. These are non-obvious behaviors an agent could easily misreport.

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-loaded with purpose, then ranked-list behavior, then the pricing/unknown nuances. Dense but each sentence carries a distinct, actionable rule. Slightly long for a query tool, though the warnings justify most of the length.

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 annotations cover only safety, so the description carries the return-shape burden — and it does: line format, chain labels, dust counts, off-page notes, and withheld balances are all described. Nothing an agent needs to interpret results correctly is missing.

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 already 100%, so baseline is 3. The description still adds real semantics beyond the schema: how minUsd produces a dust count rather than silent omission, how maxTokens interacts with unknown-priced assets, and that omitting blockchains interleaves results across chains. It stops short of documenting address format edge cases.

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?

Opens with a specific verb+resource+scope: 'Balance of an account across many blockchains, by 0x address or ENS name.' It also names the data source (Ankr Advanced API indexer) and implicitly separates itself from the sibling getBalances by noting the latter returns structured JSON.

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

Usage Guidelines5/5

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

Explicitly routes the agent: tune with maxTokens/minUsd for the human-readable list, or 'call getBalances for structured JSON.' It also warns that omitting `blockchains` queries every chain, which is the key decision point for this tool.

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

Deploy Server

Other Tools