Moby

My balance of one token

get_my_token_balance

Read-only

How much of ONE token the user holds right now, and what it is worth. The cheapest way to answer 'do I have any X', and the tool to size a sell from before placing one.

⭐ balance_token_amount IS THE ANSWER. It is the on-chain balance and it always agrees with get_my_balances. HOW MUCH THE USER HOLDS comes from the CHAIN and is reported by get_my_balances, get_my_token_balance and get_my_position (balance_source: "chain"). WHAT IT COST — cost basis, average entry, realised PnL, trade history — comes from Moby's swap ledger, which only sees swaps Moby executed. Never quote a ledger quantity as the amount held: on live accounts it runs several times high AND several times low against the chain, and a sell sized from it fails on-chain.

ledger_balance_token_amount and cost_basis_usd are the ledger's, included for cost context only. Check ledger_present BEFORE either: false means there is no ledger row at all and both are null/unknown — do NOT read ledger_disagrees: false as 'the sources agree', because it is also false when there is nothing to compare. When ledger_present is true and ledger_disagrees is true they are simply different numbers about different things — normal for any token that moved without a Moby swap, not an error, and not worth reporting to the user. Never average them, and never sell the larger one.

A balance of 0 is a real answer: the user does not hold this token. Use get_my_balances when you need everything they hold, and get_my_position when you also need unrealised PnL. This returns the CURRENT USER's own data, resolved from their API key. There is no way to ask about someone else's wallet with this tool.

Input Schema

Name	Required	Description	Default
`network`	No		solana
`token_address`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare this is a read-only, non-destructive operation, but the description adds critical context beyond them: the data is the current user's own and cannot target another wallet, a balance of 0 is a real answer, and chain balance is distinct from Moby's ledger data. It also warns about `ledger_present`, `ledger_disagrees`, and the danger of sizing a sell from ledger quantities.

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?

The answer is front-loaded in the first sentence, and the warnings are grouped into clear paragraphs. It is fairly long and occasionally repeats the same warning in different words, but the repetition is defensible given the costly failure mode it is trying to prevent.

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?

The description covers the tool's purpose, alternatives, data provenance, and key caveats, while an output schema exists to explain return fields. For a two-parameter read-only balance tool, the only notable omission is parameter-level detail, which is handled separately in the parameter semantics score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the burden of explaining `token_address` and `network`. It implies that a single token is queried and that results are scoped to the current user, but it never mentions the required `token_address` parameter, its expected address format, or the fixed `network: solana` constraint.

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 resource and scope: how much of ONE token the user holds right now and its worth. It distinguishes itself from `get_my_balances` (all holdings) and `get_my_position` (unrealised PnL), so an agent can tell when this tool is the right one.

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?

The description explicitly names the use cases: cheapest way to answer 'do I have any X' and sizing a sell before placing one. It also names alternatives and when to use them: `get_my_balances` for everything held, `get_my_position` when unrealised PnL is needed.

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

All Moby 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.

Resources

Need Help?