Skip to main content
Glama

Wallet balance

wallet_balance

Read the balances of YOUR OWN PERSONAL wallet — the funding source the crypto rails PULL from when pay_service charges a PERSONAL delegation. It answers how much do I have, and on which chain. Reading costs nothing and charges nothing. WHAT IT DOES NOT COVER, so you do not mis-diagnose: a delegation backed by an ORGANIZATION wallet is paid from that wallet, not this one; and a CARD delegation has no wallet at all — there BCK.ROUTER.0009 is the card ISSUER declining, with nothing to top up, so this tool does not apply and the answer is a different card. BY RAIL: on MPP the wallet is checked BEFORE anything is signed, and the BCK.ROUTER.0009 you get back already names the wallet and the chain — what it never says is HOW MUCH is there, which is what this tool supplies. On x402 there is NO balance pre-check and BCK.ROUTER.0009 is never raised: the credential is minted, budget is reserved, and a short wallet only surfaces when the merchant's on-chain transfer fails — by which point your budget is already committed, and the reserve comes back only once the reconciler has seen the authorization expire unconsumed. So on that rail read the balance BEFORE you pay, not after. By default this reports EVERY network this deployment settles on, and you must read the one the merchant quoted: a healthy balance on one chain says NOTHING about the other, and most services settle on only one of them. Pass network (a chain id) to read a single chain. A token whose atomic/formatted is null was NOT READ (the on-chain read failed) — that is not a zero balance, and reporting it as empty is wrong; a chain that could not be read at all comes back as an entry with error instead of balances. This tool diagnoses and fixes nothing: there is no on-ramp and you cannot top your own wallet up, so a genuine shortfall is a stop condition — report the network and the amount to your human, and do not retry the payment. Each entry with balances also carries lockedInChannels when the API reports it, per token (atomic in the token's smallest unit, formatted, symbol): money your payer wallet (the one the Router signs MPP payments with, which is this wallet once your account is migrated) has deposited into payment channels with merchants that charge per call over an MPP session, held in the channel's escrow. It is NOT part of balances and it is NOT spent: it is still the human's. It can pay further calls only to the merchant holding that channel, never anyone else, and what is unused comes back to that wallet when the channel closes, after 15 minutes without use. Report it beside the balance, never as spending, and never count it toward paying any other merchant. Here a null symbol/decimals/formatted means a token Nevermined does not recognise, NOT an unread amount: report atomic as raw units of token. An empty list means nothing is locked; lockedInChannels: null means it could not be read, which is not the same as nothing locked. When you have a Nevermined Subscription the result also carries subscription (the credits left in your monthly allowance, reset date and plan, as in get_budget): that allowance is not held in this wallet and is not money; subscription calls are paid by Nevermined, not from this wallet. Requires your Nevermined API key on the Authorization header.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
networkNoChain id to read. OMIT IT to see every network this deployment serves, which is what you want unless the merchant already told you which chain it settles on. A chain id this deployment does not serve is not refused: the result then lists the deployment's primary network (its own chain id, not the one you asked for) with a `warning` saying the requested chain is not served, so those balances say nothing about the chain you asked about.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses that reading is free, that there is no on-ramp and no self-top-up, that a shortfall is a stop condition, that null atomic/formatted means unread rather than zero, that an entry may carry `error` instead of `balances`, and that a Nevermined API key is required on the Authorization header.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the key stop-condition are reasonably front-loaded, but the body is enormously long for a one-parameter read tool, with heavy repetition around lockedInChannels, null semantics, and rail behavior. Much of the channel/subscription detail is genuinely useful, but the text could be cut substantially without losing agent-relevant meaning.

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?

There is no output schema and no annotations, so the description must define the return shape itself — and it does: `balances`, `error` entries, `lockedInChannels` with atomic/formatted/symbol, and the `subscription` block. Nothing an agent needs to interpret the response or act on a shortfall 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 100% and the schema already documents the `network` chain id and the not-served warning behavior, so a baseline of 3 applies. The description rises above baseline by explaining why the default (all networks) is usually right, why a healthy balance on one chain says nothing about another, and that balances are per-settlement-network.

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 first sentence states a specific verb and resource ('Read the balances of YOUR OWN PERSONAL wallet') and immediately delimits scope against other wallets and against the card-delegation case. An agent can distinguish it from get_budget and pay_service without opening any schema.

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?

It gives explicit when-to-use guidance by rail ('on x402 read the balance BEFORE you pay, not after'; on MPP the wallet is checked before signing) and explicit when-NOT-to-use cases (organization-backed delegations, card delegations with BCK.ROUTER.0009). It also names the alternative interpretation of the same error code.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources