Skip to main content
Glama

Rokha

by ai.rokha
OverviewDiscussionsAdmin

Get balances on one chain

singularityagent__balance
Read-only

Native and token balances for one address on one chain. Accepts ENS/SNS names and address-book aliases. On EVM chains the token scan covers a curated set of major tokens unless you pass tokens explicitly. Pass atBlock to read a past block instead of now.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainYesChain id or alias, e.g. "base", "solana", "btc".
budgetNoHow much of each list to return: 'small' (10 items, for a tight context), 'standard' (the default), 'full' (this source's maximum), or a number for an exact count. Omitting it changes nothing. Anything cut is reported in `completeness` as truncated with counts, never dropped silently.
tokensNoSpecific token contract addresses, mints, or denoms to check.
addressYesAddress, ENS/SNS name, or configured alias.
atBlockNoRead state as of this block height instead of now. Supported on EVM (needs an archive endpoint) and Cosmos (needs an archive LCD). Solana and UTXO chains reject it outright rather than answering with current state, so a result carrying `atBlock` is always genuinely historical.
includeTokensNoSet false to fetch only the native balance (faster).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / additionalProperties
      Previous value: -trueNew value: +false
    • addedInput schema / properties
      Added value: +{
+  "address": {
+    "description": "Address, ENS/SNS name, or configured alias.",
+    "type": "string"
+  },
+  "atBlock": {
+    "description": "Read state as of this block height instead of now. Supported on EVM (needs an archive endpoint) and Cosmos (needs an archive LCD). Solana and UTXO chains reject it outright rather than answering with current state, so a result carrying `atBlock` is always genuinely historical.",
+    "type": [
+      "string",
+      "number"
+    ]
+  },
+  "budget": {
+    "description": "How much of each list to return: 'small' (10 items, for a tight context), 'standard' (the default), 'full' (this source's maximum), or a number for an exact count. Omitting it changes nothing. Anything cut is reported in `completeness` as truncated with counts, never dropped silently.",
+    "type": [
+      "string",
+      "number"
+    ]
+  },
+  "chain": {
+    "description": "Chain id or alias, e.g. \"base\", \"solana\", \"btc\".",
+    "type": "string"
+  },
+  "includeTokens": {
+    "description": "Set false to fetch only the native balance (faster).",
+    "type": "boolean"
+  },
+  "tokens": {
+    "description": "Specific token contract addresses, mints, or denoms to check.",
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+}
    • addedInput schema / required
      Added value: +[
+  "address",
+  "chain"
+]
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context beyond this: the default token scan covers only a curated set on EVM chains, and `atBlock` genuinely reads past state. This informs the agent about important default behavior without contradicting the annotations.

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 three short sentences with no filler. It front-loads the core function, then adds the most decision-relevant details about name resolution, token coverage, and historical reads. Every sentence earns its place.

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

Completeness4/5

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

The description covers the key invocation decisions: what the tool returns at a high level, accepted address forms, default token behavior, and historical reads. There is no output schema, so a bit more detail on the return structure could help, but the rich parameter schema and annotations carry much of the burden.

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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that the default EVM token scan is curated and that explicitly passing `tokens` changes that behavior. It also reinforces that address parameters accept ENS/SNS names and aliases, which is useful though already present in the schema.

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?

The description states a specific verb and resource: 'Native and token balances for one address on one chain.' The title and first sentence explicitly scope it to a single chain and single address, which clearly distinguishes it from broader portfolio or multi-chain tools among the siblings.

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?

The description gives clear contextual guidance: it explains that ENS/SNS names and aliases are accepted, that the EVM token scan is curated unless `tokens` is passed, and that `atBlock` enables historical reads. It does not explicitly name alternatives or state when not to use the tool, but the single-chain scoping is unambiguous.

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

All Rokha toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources