Retrieve stablecoin balances per asset and network to verify transfer eligibility from your prefund balance.
Get your organisation's stablecoin balance, one entry per asset and network held. Also says whether transfers may be paid from it (transfers_enabled), which create_transfer with fundingSource 'prefund_balance' needs.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v2.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose useful return structure (one entry per asset and network) plus a semantic field (transfers_enabled) and its cross-tool dependency. It does not describe auth requirements or the full response shape, but for a zero-parameter read operation this is meaningful added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences, front-loaded with the core purpose followed by the one non-obvious field and its downstream use. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must convey the return shape, and it does provide the key structural fact (per asset/network entries) and the significant transfers_enabled flag. It is close to complete for a zero-param read tool, missing only full field-level return detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and nothing in the description misleads on inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get your organisation's stablecoin balance') and clarifies the granularity ('one entry per asset and network held'), which helps distinguish it from the wallet-scoped sibling. It does not explicitly contrast with get_balance_wallet or list_pending_balance_deposits, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the mention that transfers_enabled is what create_transfer with fundingSource 'prefund_balance' needs tells the agent why the field matters, but there is no explicit 'use this when / not when' guidance and no differentiation from the other balance-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.