Moby

My position in a token

get_my_position

Read-only

The user's position in ONE token: how much they hold, what they paid, and their unrealised profit or loss. Use this for 'am I up on X'. Amounts are in token units and USD; profit figures are USD.

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.

Reading the numbers — they are NOT all measured over the same quantity, and the response names which is which:

balance_token_amount / balance_usd — what the user holds ON CHAIN right now, and what all of it is worth. This is the answer to 'how much do I have'.
cost_basis_usd / current_pnl_usd / current_pnl_pct — UNREALISED, measured over basis_known_token_amount only: the part of the holding Moby has a cost for. If that is smaller than balance_token_amount, the rest arrived by transfer or airdrop and has no known basis — say so rather than implying the PnL covers everything.
invested_usd / sold_usd — LIFETIME totals ever spent and ever received, including tokens long since sold. A DIFFERENT denominator from cost_basis_usd, which covers only the tokens still held. balance_usd + sold_usd - invested_usd is net LIFETIME cash flow and will NOT equal current_pnl_usd — both are correct at their own scope, so never present one as a check on the other.
realized_total_usd — realised PnL to date, including partial sells on a position still open (realized_open_cycle_usd) as well as completed round trips (realized_closed_cycles_usd). closed_trades_count counts only the completed round trips, so it is legitimately 0 while realised PnL is non-zero.
ledger_present: false means Moby has NO swap history for this token (it arrived by transfer or airdrop), so EVERY money field above is unknown rather than zero, whatever number it carries, and ledger_balance_token_amount is null.

A null profit field means UNKNOWN — no cost information — never zero and never break-even.

take_profit_orders_count / stop_loss_set INCLUDE the TP/SL legs you placed with create_order; get_my_orders lists them.

closed_cycles — the last 5 fully closed buy→sell cycles on this token, newest first (when, avg entry/exit, size, PnL); closed_cycles_count is the total. Tx hashes and per-fill legs: get_my_closed_trades(token_address). rationale is the thesis you gave on the open cycle's latest buy, null when none. 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?

Goes well beyond the read-only/idempotent annotations by explaining that the result is always the API key's own data, that there is no way to query another wallet, how null money fields mean unknown rather than zero, and what ledger_present: false implies. It also warns that lifetime invested/sold totals use a different denominator from current cost basis, which prevents a common analytical error.

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?

Front-loaded and well organized with bullets, and much of the detail is genuinely useful for avoiding misinterpretation. However, the description is extremely long for a two-parameter read tool, and it duplicates a lot of return-field semantics that an output schema can carry, so it is dense rather than concise.

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?

Given the complexity of mixing chain balances with a swap ledger, the description covers the critical edge cases: unknown versus zero, scope differences between PnL measures, ledger-present false, TP/SL inclusion, and closed-cycle history. With an output schema present, it does not need to explain return formatting, and it leaves no major behavioral gap for calling the tool correctly.

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 compensate for parameter meaning, but it does not explain token_address or the network field. The phrase 'ONE token' and the incidental token_address in the get_my_closed_trades reference give a hint, but there is no description of required format or what network does.

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 resource and scope: the current user's position in exactly one token, including holdings, cost, and unrealised PnL, with the example query 'am I up on X'. It explicitly separates itself from sibling tools like get_my_balances and get_my_token_balance, so an agent can choose it without opening the 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?

Gives explicit usage guidance ('Use this for am I up on X') and names the alternatives for the underlying data: chain balances from get_my_balances/get_my_token_balance, and per-fill legs from get_my_closed_trades. It also states a strong when-not-to: never quote a ledger quantity as the amount held, because ledger and chain amounts diverge.

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?