Problee

Get token balances for a wallet

problee_get_balance

Read-onlyIdempotent

Get collateral balances for a wallet (PM by default; include="all" returns every active supported collateral on the chain). Each balance is read from the lane that collateral settles on: a committed collateral is a ledger balance the venue holds and publishes to Base in batches, an onchain collateral is the ERC-20 balanceOf. Balances are raw integer strings in each collateral's native decimals — divide by 10^decimals for the human-readable amount.

Input Schema

TableJSON Schema

Name	Required	Description
`chainId`	No	Active chain to query. Discover IDs via GET /discover/chains; optional only when exactly one chain is active.
`include`	No	default returns the PM balance only. all returns every active supported collateral on the chain.
`walletAddress`	Yes	Wallet to check (0x + 40 hex).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 2, 2026
- addedOutput schema / $defs / BalanceResponse / items / properties / balancePm
```
Added value: +{
+  "pattern": "^(?:0|[1-9]\\d*)(?:\\.\\d{1,6})?$",
+  "type": "string"
+}
```
First observedSep 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover safety (readOnly, idempotent, openWorld, non-destructive), and the description adds real behavioral depth beyond them: balances come from the lane the collateral settles on (committed ledger balance batched to Base vs onchain ERC-20 balanceOf), and values are raw integer strings in native decimals requiring division by 10^decimals.

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?

Three tight sentences, front-loaded with purpose then mechanics. The lane/decimals explanation is dense but each clause earns its place; no filler or repetition of the title.

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?

With an output schema present and annotations covering the safety profile, the description need only supply what structured fields omit, and it does: balance-source semantics, the default/all scope, and the decimals conversion caveat. Nothing essential for a correct call 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 description coverage is 100%, so the baseline is 3; the description nonetheless adds meaning the schema lacks, clarifying that a committed collateral is a venue-held ledger balance and an onchain one is an ERC-20 balanceOf, plus the decimal-string formatting of returned amounts.

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 ('Get collateral balances for a wallet') and immediately scopes it (PM by default, include="all" for every supported collateral). Distinguishable from the nearby list_collateral, which enumerates available collaterals rather than a wallet's balances.

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?

Explains the include default-vs-all condition and that chainId is optional only when a single chain is active, giving clear context for invocation. It stops short of naming an alternative sibling (e.g. get_positions) or stating when-not to use this tool, so it is clear but not fully routing.

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

All Problee tools Inspect

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.