Moby

Cancel one resting order — or a whole DCA schedule — so it can no longer fire. Pass EXACTLY ONE of `order_id` (from `get_my_orders`) or `schedule_id` (from `get_my_dca_schedules`; stops every remaining slice, filled slices stay filled). This does not move funds, but it is not reversible — a cancelled stop-loss stops protecting the position, and re-placing it will be at whatever price is available then. Confirm with the user which order they mean when they have more than one. Cancels are never blocked by the user's order-type switches.

Place a resting order that executes later when its condition is met: a limit order, take-profit, stop-loss, trigger buy, or a DCA schedule. ⚠[U+FE0F] THIS SPENDS REAL MONEY. It submits a real transaction from the user's wallet using real funds and cannot be undone. Confirm the exact amount, token and network with the user in plain language, and get their explicit go-ahead, BEFORE calling this. It commits the user's funds to a trade that can fire while they are not looking. Read back the full order — type, token, amount, every price — and get an explicit yes before calling. Trade limits: a SELL order (TP, SL, limit or DCA sell into the USD stable) never counts toward or is blocked by `maxTradeUsd` / `dailyVolumeUsd`. A BUY order is checked against both and reserves its USD value in the daily volume when placed; if it is cancelled, expires or fails, the unfilled part is given back. `order_type` selects what to place, and which price arguments are required: - `limit_buy` — buy when the price falls to `limit_price`. Needs `limit_price`. `amount` is the amount of the FUNDING asset to spend. - `limit_sell` — sell when the price rises to `limit_price`. Needs `limit_price`. `amount` is the amount of the held token to sell. - `tp_only` — take profit: sell when the price rises to `take_profit_price`. Needs `take_profit_price`. - `sl_only` — stop loss: sell when the price falls to `stop_loss_price`. Needs `stop_loss_price`. - `trigger_buy` — buy when the price DROPS to the trigger. The trigger goes in `stop_loss_price`; no other price. `amount` is the FUNDING asset to spend. - `sl_and_tp` — a BRACKET: stop loss AND take profit on one position in ONE call. Needs `stop_loss_price` and `take_profit_price`; `amount` is the held token, and both legs cover it (whichever fires first sells it). It places TWO orders, a stop loss and a take profit: the result says `order_type: "sl_and_tp"` and lists them in `legs` (`order_id` + `order_type` each; also `stop_loss_order_id` / `take_profit_order_id`). When one fills, Moby cancels the other. If ONE leg could not be placed, `failed_leg` says which and `failed_leg_error` why — the other leg is LIVE and stays; place only the missing one with `sl_only` / `tp_only`, never the bracket again. - To protect a position on BOTH sides use `sl_and_tp`, or `tp_only` and `sl_only` as two calls (back to back is fine). Cancelling one leg does NOT cancel the other. When one FILLS and that sells the whole position, Moby cancels your remaining exits on that token within a minute or two (a full `quick_sell` cancels them in the same call); after a PARTIAL exit the other stays live. `get_my_orders` (`status="terminal"`) then shows it with `cancel_reason`. - `dca_buy` / `dca_sell` — split the trade into `order_count` equal slices `interval_seconds` apart. Needs both, and NO price argument. All prices are USD prices of the token. `amount` is always what the user SPENDS: the funding asset on a buy, the token itself on a sell. Refusals that are NOT argument problems: `no_market` (no sell route for a new token yet — wait and retry the same call later) and `stop_above_market` / `tp_below_market` (price already past the trigger — re-check the price and pick a new trigger). Deciding to retry or re-place is your job; Moby does not retry or re-arm for you. To CLOSE or trim a position at market now, use `quick_sell` — not an order here. EXITS ARE YOURS: Moby attaches no automatic TP/SL to your buys. Place a position's take-profit / stop-loss here (`sl_and_tp`, or `tp_only` / `sl_only`) after the buy. SOL positions: use quick_sell; TP/SL on SOL is not supported yet.

Execute a swap that `get_swap_quote` already priced. ⚠[U+FE0F] THIS SPENDS REAL MONEY. It submits a real transaction from the user's wallet using real funds and cannot be undone. Confirm the exact amount, token and network with the user in plain language, and get their explicit go-ahead, BEFORE calling this. Only ever pass a `quote_id` returned by `get_swap_quote` in this same conversation, after showing the user that quote's numbers and receiving an unambiguous yes. Never call this to 'check' anything. If it answers that the quote expired, get a fresh quote — never re-send the old quote_id. AMOUNTS: read the `_ui` fields (whole tokens) when talking to the user — the un-suffixed `output_amount` / `minimum_output_amount` / `filled_*_amount` are in the token's SMALLEST unit. A null amount is unknown, never zero: `fill_pending: true` means the trade was submitted but its fill is not booked yet — say so, and read the received amount from `get_swap_status` rather than guessing it.

Buy a token in one step, without a separate quote. ⚠[U+FE0F] THIS SPENDS REAL MONEY. It submits a real transaction from the user's wallet using real funds and cannot be undone. Confirm the exact amount, token and network with the user in plain language, and get their explicit go-ahead, BEFORE calling this. Because there is no quote step, the user does not get to see a price before committing — so confirm the token AND the amount in words first, and prefer `get_swap_quote` + `execute_swap` whenever the user might want to see the price. Give exactly one of `amount_usd` or `amount_in`, never both. Verify the contract address came from `search_tokens`; buying an impostor token is unrecoverable. Response includes `quote_id`; when `fill_pending` is true, call `get_swap_status(request_id=quote_id)`. AMOUNTS: read the `_ui` fields (whole tokens) when talking to the user — the un-suffixed `output_amount` / `minimum_output_amount` / `filled_*_amount` are in the token's SMALLEST unit. A null amount is unknown, never zero: `fill_pending: true` means the trade was submitted but its fill is not booked yet — say so, and read the received amount from `get_swap_status` rather than guessing it. Moby attaches no exits: place this position's TP/SL yourself with `create_order`.

Sell a token the user holds, in ONE step, at market — quote and execute happen together on the server, so it never fails on an expired quote while you wait for the user. This is THE tool to close or trim a position. ⚠[U+FE0F] THIS SPENDS REAL MONEY. It submits a real transaction from the user's wallet using real funds and cannot be undone. Confirm the exact amount, token and network with the user in plain language, and get their explicit go-ahead, BEFORE calling this. Confirm the token and how much (`pct` of the position, default 100 = sell it all) in words first. Sizing: `pct` is a percent of the CURRENT on-chain balance (the `get_my_token_balance` number); omit it to sell everything. Proceeds land in USDC in the same agent wallet — `output_token` names it. Response: `sold_amount` (token units submitted), `pct`, `status`, `transaction_signature`, the expected proceeds (`quoted_output_amount_ui`, at least `minimum_output_amount_ui`), `slippage_bps`, and the received amount (`filled_output_amount_ui`) once booked. Response includes `quote_id`; when `fill_pending` is true, call `get_swap_status(request_id=quote_id)`. AMOUNTS: read the `_ui` fields (whole tokens) when talking to the user — the un-suffixed `output_amount` / `minimum_output_amount` / `filled_*_amount` are in the token's SMALLEST unit. A null amount is unknown, never zero: `fill_pending: true` means the trade was submitted but its fill is not booked yet — say so, and read the received amount from `get_swap_status` rather than guessing it. Selling the whole position also cancels EVERY resting TP/SL order on that token (all lots) in the same call: `cancelled_order_ids` lists them, `cancel_failed_order_ids` / `cancel_pending_order_ids` (+ `cancel_note`) any not cancelled yet, which Moby keeps retrying. A partial sell leaves them (those fields are null). A sell is never blocked by market cap, safety rating or the trade limits (and does not use up the daily volume), but the `market` order-type switch applies (a refusal comes back as `{blocked: true, reason, ...}`).

Follow a PUBLIC whale/KOL/trader wallet, so its trades appear in `get_my_following_feed`. Idempotent — following an already-followed wallet is a no-op and does not count against the follow cap (`max_follows` on `get_my_followed_wallets`). Moves no money and needs no agentic wallet. Fails if the caller is already at the cap.

START HERE for pre-buy research on one token: a compact brief (a few KB) in one call instead of 5-10. Sections: `about` (description, socials, age, launchpad; `liquidity_source`, and `graduation_pct` while on a bonding curve), `safety` (`safety_tier` + `safety_note`), `smart_money_flow` (h1/h4/h24 net $, buy vs sell counts, `last_buy_at` / `last_sell_at`, `data_as_of`), `smart_money_read` (`tier` graded over `tier_window` = 1h, headline, bullets, `concentration`, `tier_cap_reason`), `risk_signals` (snipers / insiders / bundlers / dev hold / authorities, `status`), `key_holders` (top 10 positions >= $100: size, entry MC, `last_tx`, per-coin `position`, 30-day `win_rate` / `realized_pnl_30d_usd`), `recent_quality_trades` (newest 10 tracked trades among the last 100 by wallets with win_rate >= 0.5 AND 30-day realized P/L > 0; `wallet_list_type`, `quick_flip`, `days_since_prev_trade`) and `market` (market cap, `fdv`, `ath_market_cap`, `ath_fdv`, liquidity, 24h volume, `pct_from_ath` on the `market_cap_basis` pair). Each section carries its own `computed_at` / `data_as_of`. A failed section is null with its reason in `errors`; the rest are still valid. Cached 15 s. Go deeper with `get_token_key_holders` (paging, claim tags), `get_token_live_feed` (every trade), `get_whale_wallet_profiles` (rate holders), `get_token_risk_signals` (re-poll a `pending` scan), `get_token_ohlcv` (price action) and `get_token_overview` (the full read). `safety_tier`: green = verified; grey = usually fine (not scored yet or a young launchpad token, NOT a red flag — do not skip a coin for being grey); red = caution / DYOR, the only tier to treat as a warning (Moby refuses agent buys on red). `data_notes` lists the fields Moby lacks or knows only in part (`launchpad` unknown, a `market_cap` that may count one chain of a multichain coin, no `holders_count`, an unscored `safety_tier`, a risk scan that is not `ok`), each with what to verify on the web. When Moby lacks a data point (a null field, or one listed in `data_notes`), check the web (the project's site, docs or API, DexScreener, X) before quoting it, and never present a Moby-only number as the whole picture. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Record what you run, so other sessions and clients see it. - START: omit `active_strategy_id`; pass `strategy_id` for a starter card (its name is used if you omit `name`) or `name` for a custom one, plus `settings` (the numbers the user confirmed: amounts, mix, exits, the ask-first flag) and `schedule` in plain words ('every 4 hours'). - PAUSE / RESUME / STOP: pass `active_strategy_id` and `status` paused / active / stopped. - EDIT: pass `active_strategy_id` and only the fields that changed (an empty value clears `settings`, `schedule` or `notes`). - HEARTBEAT: after each run, pass `active_strategy_id` and `last_run_at` (now, ISO 8601). At most 20 active or paused per user; stop one to start another. This moves no money and changes no guardrail.

Save the user's interview answers, or record that they skipped. Call it after you played the answers back in TWO lines and the user said yes; or with `skipped: true` when they decline. Pass `profile` OR `skipped`, not both. - `replace: false` (default) MERGES into what is saved, so for 'update my trading profile' send only the changed fields. `replace: true` overwrites the whole profile. - Amounts are USD. If the user spoke in SOL, convert at the current price and say both. - After the save, the closing step: offer one or two cards from the result's `recommended_strategies`. `strategies_followup`, when present, is that step as an instruction to you: follow it once, do not read it out. - The scan schedule has no field here. The scan schedule is kept on the agent's side, never saved to Moby: keep it in your own memory or as a recurring task in your own app, and recreate it at the start of each session. This changes NO guardrail and moves no money; the guardrails still decide what you may trade.

Log a bug, a wrong number (data_issue, name the tool) or an idea to improve Moby, once per issue; tell the user it was logged with its id. Not for payments, lost funds or account problems: send those to support in the Moby app. `kind`: bug (something broke), data_issue (a Moby number looks wrong; `tool_name` is required, and `expected` / `actual` help), idea (a missing tool or 'they should add X'). `title` is one line (max 160 chars); `details` is what happened (max 2000 chars). The same title within 24 hours returns the earlier submission with `duplicate: true` instead of a new one. At most 10 a day. Moves no money.

Unfollow a wallet. Idempotent — a no-op if the caller does not follow it. Also clears the caller's Following-feed history for this wallet, so `get_my_following_feed` reflects the change immediately. Moves no money.

The Find-Wallets suggested pool: PUBLIC wallets ranked for discovery, `is_following` marked per row. With `query` set, searches by name/brand or an exact pasted address (followed wallets ARE included). With no `query`, returns a ranked pool that EXCLUDES wallets the caller already follows — use `get_my_followed_wallets` to see those. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The high-risk ('degen') leaderboard: newer, smaller, far more volatile tokens than `get_screener_leaderboard`. Tokens here can lose most of their value in minutes and many are short-lived. Say that plainly when you present them. Ranked best-first; page 1 is the top. Moby's leaderboards: Main = `get_screener_leaderboard` (composite 24h activity, 'what's moving'); Degen = `get_degen_leaderboard` (newer, smaller, higher risk); Majors = `get_group_leaderboard(group_id="home_majors")`; Stocks = `get_group_leaderboard(group_id="home_stocks")` (tokenized stocks); Pulse = `get_group_leaderboard(group_id="home_pulse")`. The Solana group ids `majors_solana` / `stocks_solana` work too, and the `home_*` ids are listed under `home_tabs` in `get_screener_groups`. The Majors and Stocks boards are THE reference for major and tokenized-stock contract addresses: take `token_address` from the row. Never resolve a major or a stock by ticker search alone, and never keep your own mint list. Results are capped. Raise `limit` or step `page` only if the answer is genuinely not in the first page — a large result costs context that later steps of the same task need. `whale_windows` (any of h1/h4/h8/h24) adds a per-row `whale` block per window: whale_count (distinct tracked wallets that bought OR sold — buyers plus sellers, not buyers alone), whale_buyers_count (distinct buyers only), whale_buys_count, whale_sells_count and whale_net_flow_usd. The row's `whale_count_h24` is the same buyers-plus-sellers count. Null figures mean unknown. `asset_class: tokenized_stock` marks tokenized equities (treat as stock proxies, not memecoins). `safety_tier`: green = verified; grey = usually fine (not scored yet or a young launchpad token, NOT a red flag — do not skip a coin for being grey); red = caution / DYOR, the only tier to treat as a warning (Moby refuses agent buys on red). This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The ranked tokens inside one group/category. `group_id` must come from `get_screener_groups` — a group's `group_id`, or a `home_tabs` `tab_id` such as `home_majors` / `home_stocks` — do not invent or guess one. Ranked best-first; page 1 is the top. Moby's leaderboards: Main = `get_screener_leaderboard` (composite 24h activity, 'what's moving'); Degen = `get_degen_leaderboard` (newer, smaller, higher risk); Majors = `get_group_leaderboard(group_id="home_majors")`; Stocks = `get_group_leaderboard(group_id="home_stocks")` (tokenized stocks); Pulse = `get_group_leaderboard(group_id="home_pulse")`. The Solana group ids `majors_solana` / `stocks_solana` work too, and the `home_*` ids are listed under `home_tabs` in `get_screener_groups`. The Majors and Stocks boards are THE reference for major and tokenized-stock contract addresses: take `token_address` from the row. Never resolve a major or a stock by ticker search alone, and never keep your own mint list. Results are capped. Raise `limit` or step `page` only if the answer is genuinely not in the first page — a large result costs context that later steps of the same task need. `whale_windows` (any of h1/h4/h8/h24) adds a per-row `whale` block per window: whale_count (distinct tracked wallets that bought OR sold — buyers plus sellers, not buyers alone), whale_buyers_count (distinct buyers only), whale_buys_count, whale_sells_count and whale_net_flow_usd. The row's `whale_count_h24` is the same buyers-plus-sellers count. Null figures mean unknown. `asset_class: tokenized_stock` marks tokenized equities (treat as stock proxies, not memecoins). `safety_tier`: green = verified; grey = usually fine (not scored yet or a young launchpad token, NOT a red flag — do not skip a coin for being grey); red = caution / DYOR, the only tier to treat as a warning (Moby refuses agent buys on red). This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Tracked KOLs — named public traders/influencers — holding this token. The KOL-only slice of `get_token_key_holders`. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Tokens grouped by the launchpad they were created on (pump.fun and similar). Useful for 'what launched recently' questions. Newly launched tokens are the riskiest category on the platform. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Screener events — discrete things that happened to tokens (price and volume moves, notable activity) over a period, newest first. This is the event stream behind the leaderboards, so use it when the user asks what CHANGED or what HAPPENED rather than what ranks highest right now. Poll for new events with `after_timestamp`; page back through history with `before_timestamp`. Each event carries flat `token_symbol`/`token_address`, `liquidity_usd` and h1/h4 smart-money flow (`smart_money_net_flow_usd`, `smart_money_buys_count`, `smart_money_sells_count`) — those are AS OF NOW (read time), while `market_cap_usd` and `price_usd` are AT THE TIME OF THE EVENT. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The strategies the user's agents are running, saved on Moby so every client and session sees them: `name`, `strategy_id` (the starter card, null = custom), `settings`, `schedule`, `status` (active / paused; pass `include_stopped=true` for stopped ones too), `started_at`, `last_run_at`. Call it at the start of every session to learn what is already running, and before starting a strategy, so two sessions never run the same one twice. Resume what is `active` on its `schedule`; leave `paused` ones alone unless the user asks. `app_links` are Moby app deep links to hand to the user; they open the Moby app on their phone. 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.

The user's own wallet activity feed — their trades, transfers, deposits and withdrawals, newest first. ⚠[U+FE0F] This one is CURSOR-paginated, not page-numbered: read `cursor` out of the response and pass it back to get the next page. Do not send a page number. Choosing between the two history feeds: `get_my_activity` is the merged, human-readable timeline the app shows, cursor-paginated. `get_my_transactions` is the raw transaction list, page-numbered and filterable by transaction type. Prefer activity for 'what have I been doing'; use transactions when you need a specific type such as deposits. 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.

The user's CURRENT holdings in their Solana agent wallet, with balances and USD values. USDC is your cash (flagged `is_cash: true`). SOL and every other token are positions; sell with quick_sell to raise USDC. What each part contains: - `tokens` — EVERYTHING held in the wallet, and the authoritative answer to 'what do I own'. It INCLUDES the native coin (SOL, flagged `is_native: true`) and the USD funding asset (USDC, flagged `is_quote: true`) whenever their balance is above zero; every other row has both flags false. An empty `tokens` means the wallet really is empty. - `native_token` / `usd_token` — the same native-coin and funding-asset balances again, as fixed slots that are present even at zero. Use them for the affordability check; never add them to the `tokens` total, they are already in it. - Native SOL is read from the CHAIN at call time: `balance_source: "chain"`. If that read failed it is Moby's stored snapshot instead (`balance_source: "ledger"`) — say the SOL figure may be stale. `ledger_disagrees: true` only means the stored snapshot was wrong; the quantity shown is the chain's. - `swap_user_tokens` — the swap LEDGER: cost basis and PnL per position. Its quantities are NOT the amounts held; where it disagrees with `tokens`, `tokens` is right. 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. IMPORTANT: `get_my_closed_positions` returns ONLY positions the user has already exited. Positions the user still holds come from `get_my_balances`. Never tell a user they hold nothing based on `get_my_closed_positions` being empty. `asset_class: tokenized_stock` marks tokenized equities (treat as stock proxies, not memecoins). ⚠ ONE WALLET. For the agent's equity as a single total, call `get_my_portfolio` instead; this tool is the right one for the per-token detail and for the affordability check before a trade. Balances other than native SOL come from a cached snapshot that lags a deposit made outside Moby. If the user says they just funded the wallet and the balance does not show it, call this ONCE more with `refresh=true` before telling them anything is wrong — their money is on chain either way. Do not pass `refresh` routinely: it is much slower. USDC split (ENG-1803): `available_usdc` is the USDC spendable NOW — size buys from it. `reserved_usdc` is USDC already committed to the user's resting DCAs and limit / trigger buy orders; it comes back only by cancelling them (`cancel_order`). `reserved_breakdown` lists each one (`kind` dca|order, `schedule_id` / `order_id`, token, `reserved_usd`, `remaining_slices`, `next_order_at`); `in_wallet: true` means that USDC still sits in the wallet balance until the order pulls it, so do not spend it twice. This is NOT the daily-volume `daily_volume_reserved_usd` in `get_my_guardrails` — that is spend-cap accounting over a rolling 24h. All three are null when Moby could not read the orders: then check `get_my_orders` before spending. `app_links.deposit` is where the user adds funds; `app_links.settings` is their limits. `app_links` are Moby app deep links to hand to the user; they open the Moby app on their phone. `interview_due: true` (the first read each hour also carries `onboarding_hint`) means the user was never onboarded: go back to onboarding FIRST — `get_my_trading_profile`, the capabilities brief, the 6-question interview or skip — before you act on these numbers. 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.

🔴 CLOSED POSITIONS ONLY — positions the user has already fully exited, with their realised profit and loss. IMPORTANT: `get_my_closed_positions` returns ONLY positions the user has already exited. Positions the user still holds come from `get_my_balances`. Never tell a user they hold nothing based on `get_my_closed_positions` being empty. Use this for realised PnL questions. An empty result means the user has never closed a position, and says nothing at all about what they hold today. Choosing between the two history tools: `get_my_closed_positions` is the POSITION-level rollup — one entry per token the user entered and fully exited, with total realised PnL. `get_my_closed_trades` is the individual TRADES underneath, one entry per fill. Use positions for 'how did I do on X', trades for 'show me every trade'. 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.

The user's completed trades, newest first — one entry per closed buy→sell cycle, with what was bought or sold and the realised result. Each cycle carries `fills`: every buy/sell leg with timestamp, side, price_usd, token_amount, usd_amount and tx_hash (pass `include_fills=false` to skip them), plus the `rationale` you gave for it (null when none). Choosing between the two history tools: `get_my_closed_positions` is the POSITION-level rollup — one entry per token the user entered and fully exited, with total realised PnL. `get_my_closed_trades` is the individual TRADES underneath, one entry per fill. Use positions for 'how did I do on X', trades for 'show me every trade'. IMPORTANT: `get_my_closed_positions` returns ONLY positions the user has already exited. Positions the user still holds come from `get_my_balances`. Never tell a user they hold nothing based on `get_my_closed_positions` being empty. ⚠[U+FE0F] ONE TOKEN AT A TIME: `token_address` is REQUIRED. The backing service formats a per-token history and has no cross-token mode. For the user's whole trading history across tokens, call `get_my_closed_positions` instead. 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.

The user's DCA schedules — recurring buys or sells that split an amount into slices over time — with progress so far (how many slices have filled and when the next one is due). The same rows `get_my_orders` returns as `dca_schedules`; use this one when you only need the DCAs. `get_my_orders` answers 'what do I have running' in ONE call: `orders` (limit, take-profit, stop-loss) plus `dca_schedules` (DCA schedules, one row per schedule; a DCA's individual slices never appear in `orders`). `get_my_dca_schedules` is the same DCA rows on their own. If `dca_schedules` is null, the DCA read failed (`dca_schedules_error`): call `get_my_dca_schedules` before telling the user they have no DCA running. By default only live schedules are returned; set `include_terminal` to also see finished and cancelled ones. To stop a whole DCA, pass its `schedule_id` to `cancel_order`. 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.

Your earlier submissions and their status; mention a shipped one to the user when relevant. Each has `id`, `kind`, `title`, `status` (new / reviewed / planned / shipped / wont_fix) and the team's `reply` when there is one, newest first. 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.

Every wallet the CALLER follows, with `max_follows` so you can report 'N of 50' without a second call, each row's current list associations, and any nickname set with `follow_wallet`. 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.

Trades made by wallets the CALLER follows, newest first. ⚠[U+FE0F] EMPTY MEANS 'you follow nobody, or nobody you follow has traded recently' — NOT 'no whale activity anywhere'; for the market-wide feed use `get_whalewatch_feed`. Filters mirror that tool minus list selection, since following is orthogonal to lists. Results are capped. Raise `limit` or step `page` only if the answer is genuinely not in the first page — a large result costs context that later steps of the same task need. 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.

The limits the user set on you in the Moby app, READ-ONLY — you cannot change them; only the user can, in the app. Read this before planning trades instead of discovering limits by refusal. - `maxTradeUsd` / `dailyVolumeUsd`: per-trade and rolling-24h trading-volume limits (null = uncapped). `maxTradeUsd` caps BUYS only — any sell passes it, whatever the size or output. Buys (and any other swap) count when placed or filled; sells into the USD stable (USDC) never count or get blocked — swaps and TP/SL/limit sell orders alike; cancelled buy orders give their reservation back. `dailyVolumeUsedUsd` = `dailyVolumeExecutedUsd` (traded) + `dailyVolumeReservedUsd` (unfilled buy orders still resting); the room left is `dailyVolumeUsd - dailyVolumeUsedUsd`. - `defaults_applied`: a list of limit names, e.g. `["maxTradeUsd", "dailyVolumeUsd"]`, that are Moby's defaults because the user has not saved their own (empty `[]` when every limit is the user's). Enforced all the same; call them Moby's default limits, never limits the user set. - `minCapUsd` / `maxCapUsd`: market-cap band for BUYS (null = no bound). - `orderTypes`: which kinds you may place (`market` covers swaps, `quick_buy` and `quick_sell`). Cancels are never blocked. - `paused`: true = every trade is refused until the user resumes you. - `platform_limits`: Moby's own trade-rate limits for this key. - `app_links.settings` is where the user changes these limits; `app_links.deposit` is where they add funds. `app_links` are Moby app deep links to hand to the user; they open the Moby app on their phone. 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.

The user's single orders — limit orders, take-profit and stop-loss. By default only LIVE ones (not executed yet): use that before placing a new order (to avoid duplicates) and to find an `order_id` for `cancel_order`. For HISTORY — what filled, what was cancelled and why — pass `status="terminal"` (optionally with `since`/`until`). Filled rows carry `filled_price`, `fill_tx_hash` and `slippage_vs_trigger_pct` (signed, vs the trigger that fired); cancelled rows carry `cancelled_at` and `cancel_reason` (`sibling_filled` = Moby closed out this exit after the other one sold the position; `position_closed`, `user`, `expired`, `failed`, `unknown`). History is paged: `limit` (default 50, max 200) newest-first rows per `page`; step `page` only if the answer is not on the first one. Pass `token_address` to see only one token's orders (matches the token being sold or bought); without it every order on the wallet comes back. Reading a row: `input_*` is what the user SPENDS (the funding asset on a buy — USDC), `token_*` is the SUBJECT token the order is about, and every price is quoted against the subject token. Describe an order by `token_symbol`, never by `input_token_symbol`. ⚠[U+FE0F] If a row carries `data_warning`, it contradicts itself — report its state as unclear rather than choosing one of the readings. `origin: agent` is an order you placed; `origin: agent_auto_exit` is an older exit Moby attached before automatic exits were retired — it is still that position's exit while it rests. DCAs: `dca_schedules` lists the DCA schedules in the same call (live ones by default; finished ones too when `status` asks for history), filtered by `token_address` like the orders. Each row's `schedule_id` is what `cancel_order` takes to stop the whole DCA; report progress from `filled_order_count` / `order_count`. `get_my_orders` answers 'what do I have running' in ONE call: `orders` (limit, take-profit, stop-loss) plus `dca_schedules` (DCA schedules, one row per schedule; a DCA's individual slices never appear in `orders`). `get_my_dca_schedules` is the same DCA rows on their own. If `dca_schedules` is null, the DCA read failed (`dca_schedules_error`): call `get_my_dca_schedules` before telling the user they have no DCA running. 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.

EVERYTHING the user's agent holds, in one call — with a single combined total of the AGENT'S OWN wallets only: the user's Copy Trading wallet and manual wallets are NOT counted. `excluded_wallets` lists what was left out (shortened address, `owner_kind`, label) and `scope` is `agent_wallets`; do not add those back in — `hero_usd` is the agent's equity, the number to judge its performance and drawdown by. Start here for 'how am I doing', 'what do I own', 'what is my agent worth'. `summary.hero_usd` is the one number to quote; `summary.wallets` breaks it down per wallet; `holdings.items` is every position; `trading_balances.items` is the funding-asset balances. USDC is your cash; SOL and every other token are positions — sell with quick_sell to raise USDC. Do NOT add up `summary.wallets` yourself — `hero_usd` already is that sum, computed over the same rows. ⚠ NOT `get_my_balances`. That tool is ONE wallet's per-token detail; use it when you need to check affordability before a trade. `refresh=true` re-reads every wallet from the chain and is much slower — a vendor round trip PER WALLET. Send it only when the user explicitly asks for fresh numbers, or right after a deposit they made outside Moby that is not showing. Never routinely. `asset_class: tokenized_stock` marks tokenized equities (treat as stock proxies, not memecoins). `interview_due: true` (the first read each hour also carries `onboarding_hint`) means the user was never onboarded: go back to onboarding FIRST — `get_my_trading_profile`, the capabilities brief, the 6-question interview or skip — before you act on these numbers. 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.

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.

'For you': the tracked wallets that overlap the CALLER's OWN holdings, in the same shape as `get_whalewatch_wallet_list_detail`. A caller holding nothing Moby tracks gets `total: 0, rows: []` — that is a real answer, not an error. 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.

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.

The user's saved trading profile: experience, assets, work mode, sizing and protection (v1 rows read as v2). 🔴 Call this BEFORE ANY OTHER TOOL on every connect — before balances, portfolio, strategies or research. - `interview_due: true` = onboard first: show `onboarding_brief` verbatim, then run the skippable 5-question interview in `interview_questions`, then its closing step (TWO-line playback, `save_trading_profile`, strategy offer). The scan schedule is kept on the agent's side, never saved to Moby: keep it in your own memory or as a recurring task in your own app, and recreate it at the start of each session. - `recommended_strategies`: the live starter-strategy ids matching the user's assets; offer one or two of them (names from `list_strategies`) in the closing step. - `status`: `missing` = never asked; `saved` = answers on file, use them; `skipped` = the user declined, do not ask again unless `interview_due` is true. - The profile is the user's INTENT. `get_my_guardrails` and the Moby app caps are the enforcement and the profile can never raise them. `guardrail_conflicts` lists where the user's wish exceeds a cap; tell them Moby enforces the cap. The wallet is never a parameter. 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.

One transaction in full detail, by its id. Get the id from `get_my_transactions` first — this tool does not search or list. 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.

The user's raw wallet transaction list, newest first and page-numbered. Filter by `transaction_type` to answer questions about one kind of movement — deposits, withdrawals, swaps, transfers or trigger-order fills. Choosing between the two history feeds: `get_my_activity` is the merged, human-readable timeline the app shows, cursor-paginated. `get_my_transactions` is the raw transaction list, page-numbered and filterable by transaction type. Prefer activity for 'what have I been doing'; use transactions when you need a specific type such as deposits. 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.

The user's AGENTIC wallets, with their addresses. AI Trading is Solana only for now: tell the user to deposit to the Solana one. 🔴 THE USER'S REGULAR APP WALLETS ARE NOT HERE — an agent's world is agentic wallets only, and every other `get_my_*` tool here reads from one of these, never from the user's primary wallet. 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.

The tokens on one of the user's watchlists, each with market data in ONE call, so you can triage a list without a `get_token_overview` per token. Each row carries `price_usd`, `price_change_24hr` (24h %, there is no 1h figure here), `market_cap`, `liquidity_usd`, `whale_count`, `key_holder_count` and `token` (address, symbol, `safety_tier`). `safety_tier`: green = verified; grey = usually fine (not scored yet or a young launchpad token, NOT a red flag — do not skip a coin for being grey); red = caution / DYOR, the only tier to treat as a warning (Moby refuses agent buys on red). Omit `watchlist_id` for the user's default list on this network; otherwise pass an id from `get_my_watchlists` (an id that is not the user's is a 404). Use `get_token_overview` for the full picture of one token. Read-only. 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.

The user's watchlists on one network — names and ids only. Pass an id to `get_my_watchlist_tokens` to read a list's contents. Start here for 'what's on my watchlist' or 'anything on my watchlist moving?'. A watchlist is the tokens the user chose to follow, NOT what they hold (`get_my_balances`) and NOT other people's wallets. Read-only: adding or removing tokens is not available here. 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.

The VALID VALUES for `get_market_movers`' `event_types`, `period` and `market_cap_group` arguments, for one network. Call this BEFORE filtering `get_market_movers` — an invented filter string returns an empty list that reads as 'no events found' rather than 'you guessed a value that does not exist'. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

List the token groups/categories Moby tracks (themes, sectors, narratives). Use this to discover a valid `group_id`, then pass that to `get_group_leaderboard` to see the tokens inside it. `home_tabs` lists the app's Home boards by `tab_id` (`home_majors`, `home_stocks`, `home_pulse`), also valid `group_id`s. Moby's leaderboards: Main = `get_screener_leaderboard` (composite 24h activity, 'what's moving'); Degen = `get_degen_leaderboard` (newer, smaller, higher risk); Majors = `get_group_leaderboard(group_id="home_majors")`; Stocks = `get_group_leaderboard(group_id="home_stocks")` (tokenized stocks); Pulse = `get_group_leaderboard(group_id="home_pulse")`. The Solana group ids `majors_solana` / `stocks_solana` work too, and the `home_*` ids are listed under `home_tabs` in `get_screener_groups`. The Majors and Stocks boards are THE reference for major and tokenized-stock contract addresses: take `token_address` from the row. Never resolve a major or a stock by ticker search alone, and never keep your own mint list. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The main Moby token leaderboard: the tokens with the most notable activity right now, ranked best-first by Moby's composite 24h score. Start here when the user asks what is moving, what is trending, or what they should be looking at, and they have not named a specific token. Page 1 is the top of the board — for 'what is hot right now' the default page is the whole answer. Moby's leaderboards: Main = `get_screener_leaderboard` (composite 24h activity, 'what's moving'); Degen = `get_degen_leaderboard` (newer, smaller, higher risk); Majors = `get_group_leaderboard(group_id="home_majors")`; Stocks = `get_group_leaderboard(group_id="home_stocks")` (tokenized stocks); Pulse = `get_group_leaderboard(group_id="home_pulse")`. The Solana group ids `majors_solana` / `stocks_solana` work too, and the `home_*` ids are listed under `home_tabs` in `get_screener_groups`. The Majors and Stocks boards are THE reference for major and tokenized-stock contract addresses: take `token_address` from the row. Never resolve a major or a stock by ticker search alone, and never keep your own mint list. Results are capped. Raise `limit` or step `page` only if the answer is genuinely not in the first page — a large result costs context that later steps of the same task need. `whale_windows` (any of h1/h4/h8/h24) adds a per-row `whale` block per window: whale_count (distinct tracked wallets that bought OR sold — buyers plus sellers, not buyers alone), whale_buyers_count (distinct buyers only), whale_buys_count, whale_sells_count and whale_net_flow_usd. The row's `whale_count_h24` is the same buyers-plus-sellers count. Null figures mean unknown. `asset_class: tokenized_stock` marks tokenized equities (treat as stock proxies, not memecoins). `safety_tier`: green = verified; grey = usually fine (not scored yet or a young launchpad token, NOT a red flag — do not skip a coin for being grey); red = caution / DYOR, the only tier to treat as a warning (Moby refuses agent buys on red). This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The WHOLE MARKET's whale flow in one call: tracked whale/KOL/smart-money buys, sells and dumps for the last 1h, 4h and 24h (`h1`, `h4`, `h24`). Use it to tell 'whales are dumping everything' from 'this one coin is weak' before reading a single token, instead of paging `get_whalewatch_feed_window`. Each window has `totals`, `by_wallet_type` (whale / kol / smart_money; overlapping, a wallet on two kinds of list counts in both; smart_money is null when unknown), `fresh_launch` (`under_24h` / `under_1h`: trades in tokens launched that recently) and the top 5 tokens by net whale buying (`top_net_buy`) and selling (`top_net_sell`). Every slice has trades, tokens, buys, sells, buy/sell volume USD, net_flow_usd, distinct buyers and sellers, dump_sells (sold half or more of the position), dump_wallets and first_buys. One swap counts once; swaps under `min_trade_usd` are left out. Refreshed every ~2 minutes; `data_as_of` is when it was computed. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

One starter strategy with its ready-to-run `prompt` — the same text the app copies. Run that prompt as the user's standing instructions for this session. Before starting: confirm the editable numbers (`chips`: amounts, exits, schedule) with the user, and check `get_my_active_strategies` so you never run one twice. Once the user says go, record it with `save_active_strategy` (pass `strategy_id`). `ask_before_every_trade=true` adds the 'ask me before every trade' line, on cards that support it (`ask_line_supported`). `app_links` are Moby app deep links to hand to the user; they open the Moby app on their phone.

Price a token swap before doing it: how much of `output_token` the user would receive for `amount` of `input_token`, plus price impact, fees, the slippage tolerance (`slippage_bps`) and the least the route can deliver (`minimum_output_amount_ui`). Quote `output_amount_ui` to the user — `output_amount` is in the token's smallest unit. `pricing_basis` states what produced it. This only prices the trade. It does not move funds and nothing is submitted on-chain. Returns a `quote_id` that `execute_swap` consumes. Quotes go stale in seconds — show the numbers to the user, get their answer, and if they hesitate, quote again rather than executing an old one. Always call this before `execute_swap` so the user sees what they are agreeing to. If `execute_swap` returns `pending` or `fill_pending`, only `get_swap_status` can tell you it completed.

Check where a quote or swap stands, by `request_id` (the `quote_id`) OR `transaction_signature` — exactly one. Moves nothing and is safe to call again. `status` is one of: `not_executed` (quoted but never executed — nothing was traded; it can still be executed until `quote_expires_at`), `expired` (never executed and now too old — nothing was traded; get a fresh quote if the user still wants it), `pending` (submitted, waiting for confirmation), `confirmed`, `failed`. `executed_at` is when it was submitted (null = never). Once booked, `filled_input_amount_ui` / `filled_output_amount_ui` are what was actually spent and received and `effective_slippage_bps` how far the fill landed from the quote. A `failed` swap carries `failure_details` (`transaction_signature`, `stage`, `error_class`, `chain_error`, `provider`). `error_class` is always set for an on-chain revert: `slippage_exceeded` (requote), `insufficient_funds` / `insufficient_lamports` (the wallet could not cover the trade or SOL for fees/rent), `program_error` (a program refused it; its code is in `chain_error.code`), `unknown_revert`; `dropped_tx_blockhash_expired` means it never landed. `request_id` also accepts the Reference ID a failure message printed. A `confirmed` sell carries `resting_order_ids`: your orders still live on the token sold (empty once a full sell's exits are all cancelled). 🔴 CALL THIS WHENEVER `execute_swap` OR `quick_buy` RETURNED A `next_step`. A swap can return before its fill is confirmed. Until this tool says the swap succeeded, you do NOT know that it did: never tell the user their tokens have arrived based on the execute response alone, and never re-execute the quote to find out (that would trade twice). If it is still pending, say so and check again shortly.

Price history for one token as a series of points, for describing or plotting a trend. `period` selects the window and defaults to `1d`. Prices are in USD. Choosing between the two price tools: `get_token_chart` returns a ready-to-read price line for describing a trend; `get_token_ohlcv` returns raw open/high/low/close/volume candles for calculation and technical analysis. Prefer the chart unless you need per-candle numbers. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

PUBLIC, on-chain DCA (dollar-cost-average) orders open against this token — who ELSE in the market is accumulating it on a schedule. ⚠[U+FE0F] NOT the user's own DCAs — those come from `get_my_dca_schedules`. The two are unrelated datasets that both use the word 'DCA'. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

ALL top holders of this token, paginated and ranked by size — not just the wallets Moby tracks. `get_token_key_holders` is the tracked-whale/KOL SUBSET of this same population; this is the full concentration picture. Results are capped. Raise `limit` or step `page` only if the answer is genuinely not in the first page — a large result costs context that later steps of the same task need. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Aggregate holder-distribution summary for one token — the concentration picture in bucketed form. For the individually itemised top holders use `get_token_holders`; for just the tracked whales/KOLs use `get_token_key_holders`. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The most significant holders of this token and how concentrated ownership is. High concentration is a risk signal worth stating explicitly to the user. ⚠[U+FE0F] These are OTHER people's wallets — this is NOT the user's position in the token. For that, use `get_my_position`. `whale_count`/`trader_count`/`kol_count` (and the claim's `tag_count`, when `tag` is set) are always TRUE totals; `page`/`limit` are echoed back. Each row carries the wallet's 30-day `win_rate` and `realized_pnl_30d_usd`, and `days_since_prev_trade` / `prev_trade_at` for its latest trade in this token (how long the wallet was quiet before it, any token). Rows and counts only include positions worth at least `min_position_usd` (default $100; each row's `value_usd` lets you filter further). `position` is the wallet's tracked buys / sells of THIS token: `bought_usd`, `sold_usd`, `realized_pnl_usd`, `buys_count`, `sells_count`, `pct_of_peak_held` (0-1 of its largest tracked bag still held), `first_buy_at`, `entry_known`. Only trades Moby tracked: sells can exceed buys (transfers in, or buys before tracking). When `entry_known` is false, `realized_pnl_usd` and `pct_of_peak_held` are null (unknown, not 0); `position` is null when Moby never saw the wallet trade the token. KOL `platform` is never null: `unknown` plus `platform_reason` (`not_tagged` = no platform on record); `distinct_kol_platforms` counts the known platforms across `kols`, `unknown` excluded. Wallet quality: use get_whale_wallet_track_record(wallet_address) for a wallet's win rate and PnL. Results are capped. Raise `limit` or step `page` only if the answer is genuinely not in the first page — a large result costs context that later steps of the same task need. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Trade-by-trade feed of the TRACKED whale, KOL and trader wallets that traded one token, newest first. It is NOT the whole market: only wallets Moby tracks appear. Every tracked trade is listed, with no $ floor (the app's feed hides trades under $100). One row per swap: a wallet that is both a whale and a KOL appears once, with `identities`, `is_whale` and `is_kol` set. Rows exist from when Moby began tracking the token's traders (usually when it first trended); earlier trades are not in this feed. Pass `next_cursor` back as `cursor` for the next page until it is null. `wallet.win_rate` / `wallet.realized_pnl_30d_usd` are the wallet's 30-day quality. Each row's `days_since_prev_trade` / `prev_trade_at` say how long the wallet was quiet before the trade (any token; null = no earlier trade on record). Rows sort by `timestamp` (block time, whole seconds), then `sequence` (the order Moby ingested the trades): several trades by one wallet in the same second come back in the order their position-before values chain. Every row has `wallet_list_type` (`whale`, `trader` or `kol`). SELL rows carry `held_seconds` (since the wallet's first buy of the token) and `quick_flip: true` when it sold within 15 minutes — check for it before treating that wallet's buy as conviction; buy rows leave both null. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Raw OHLCV candles for one token — open, high, low, close and volume per interval — for calculation, technical analysis, or computing a return over a specific window. Prices are always USD (the response says so in `denomination`). Pick the candle size with `interval` (`1m`, `5m`, `15m`, `1h`, `4h`, `1d`); it wins over `timeframe` and `aggregate`. With none of the three the default is 15-minute candles; `timeframe` alone means 1 unit (`hour` = 1h). An unsupported size is rejected, never silently swapped, and the response echoes the `interval` and `candle_seconds` actually served. `t` is Unix MILLISECONDS. All three time arguments accept SECONDS or MILLISECONDS, so a `t` value from a previous response can be fed straight back. 🔴 READ BEFORE COMPUTING A RETURN — the `s/t/o/h/l/c/v` shape looks like TradingView's, and it differs from it in two ways that will silently corrupt the answer: - THE SERIES IS NEWEST-FIRST (descending `t`), not oldest-first. `c[0]` is the LATEST close and `c[-1]` is the OLDEST. A return over the window is `(c[0] - c[-1]) / c[-1]`; doing it the other way round returns the right magnitude with the WRONG SIGN. The response states this in `order`. - EVERY CANDLE RETURNED IS CLOSED. The current, still-forming interval is removed by default, because its close is a mid-bucket tick rather than a close and including it makes 'the return over the last N candles' wrong. Set `include_in_progress_candle` only if you specifically want the live, unfinished bucket — it will then be at index 0 and `includes_in_progress_candle` will be true. Choosing between the two price tools: `get_token_chart` returns a ready-to-read price line for describing a trend; `get_token_ohlcv` returns raw open/high/low/close/volume candles for calculation and technical analysis. Prefer the chart unless you need per-candle numbers. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Everything Moby knows about one token in a single call: price, market cap, liquidity, volume, holder counts, safety signals and metadata. This is the default tool for 'tell me about <token>'. Get `token_address` from `search_tokens`. `liquidity_source` says where `liquidity` sits: `bonding_curve` = a launchpad coin not yet migrated, `liquidity` is its curve reserve (0 = curve drained, everyone sold) and `graduation_pct` is % of the curve filled; `dex_pool` otherwise; null = unknown. `market_cap` is the circulating market cap (`market_cap_basis` is `circulating`), or the fully diluted value when Moby has no circulating figure (`fully_diluted`, flagged in `data_notes`). `fdv` is the fully diluted valuation (price x total supply). `ath_market_cap` (alias `ath_mc`) is the all-time-high on the same basis as `market_cap`; `ath_fdv` is the all-time-high FDV. Compare like with like: a coin is at its ATH only when `market_cap` ~= `ath_market_cap` or `fdv` ~= `ath_fdv`, never `market_cap` against `ath_fdv`. `asset_class: tokenized_stock` marks tokenized equities (treat as stock proxies, not memecoins). `safety_tier`: green = verified; grey = usually fine (not scored yet or a young launchpad token, NOT a red flag — do not skip a coin for being grey); red = caution / DYOR, the only tier to treat as a warning (Moby refuses agent buys on red). `safety_note` spells out the tier. `stats.untouched_pct` equals the `detail.tags` Untouched cell's `pct`: one window (`detail.window`, last 7 days or since launch) and one denominator (`detail.total`, current Key Holders plus wallets that sold out in the window). Each wallet gets one tag: Sold out > Trimmed (its Key Holders `story` chip is `trimming`, or it sold in the window without buying) > Added (bought in the window) > Untouched. `smart_money_read_v2` mixes two windows ON PURPOSE: `tier`/`label`/`verdict` grade the LAST HOUR of tracked-wallet flow (`tier` is green|yellow|red|holding, `label` is Buying|Holding|Selling|Mixed|Quiet); `color`/`text`/`sentences`/`bullets`/`stats` describe the 7-DAY holder base. They can disagree: green/Buying with red text means buying this hour into a base that churned all week — say both. Gate entries on `tier`, and read `text` for what the base did. `stats.left_*` is every tracked wallet that sold out (what the copy quotes); `stats.exited_*` is the entry-known subset the ratios use. `concentration` is the largest tracked holder (`supply_pct`, `bag_to_liquidity`, `multiple_on_entry`); `flagged` means one wallet carries the read or out-sizes the pool, and `tier_cap_reason: concentration` means the green hour was capped to yellow for it — treat the buying as one bag, not a crowd. `data_notes` lists the fields Moby lacks or knows only in part (`launchpad` unknown, a `market_cap` that may count one chain of a multichain coin, no `holders_count`, an unscored `safety_tier`, a risk scan that is not `ok`), each with what to verify on the web. When Moby lacks a data point (a null field, or one listed in `data_notes`), check the web (the project's site, docs or API, DexScreener, X) before quoting it, and never present a Moby-only number as the whole picture. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The current USD price of one token, and nothing else. Cheapest call for a price check; use `get_token_overview` if you also need market cap, liquidity or volume. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Holder-concentration and contract risk for one token: sniper, insider, bundler and fresh-wallet shares, dev hold, mint/freeze authority, honeypot and buy/sell tax. Same fields and rules as the Moby app's Risk Signals block. `status` is `ok` / `pending` / `unavailable` / `unsupported`: `pending` means retry in a few seconds; `unavailable` and `unsupported` mean no data (do not hammer). Nulls mean no data, not zero (all-zero holder cohorts are reported as no data). Early buyers stay `unavailable`. `fetched_at` tells how fresh the read is. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Which tracked high-performing wallets (whales, KOLs, proven traders) are positioned in this token, and on which side. This is Moby's core edge signal — it answers 'is anyone good in this?'. These are OTHER people's wallets, never the user's. Each window (`h1`, `h4`, `h24`) carries `last_buy_at` / `last_sell_at` (newest buy / sell in that window) and the response `data_as_of` (when the windows were rolled up; each ends there). A net that flips with no newer `last_sell_at` means older buys aged out, not new selling. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Tracked WHALES holding this token, GROUPED BY WHALE LIST. `get_token_key_holders` returns the same population UNGROUPED (whales and KOLs together); use this when the question is 'which KIND of whale is in this'. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The project's X/Twitter account: follower count, age, verification — 'is this project's social presence real or a two-day-old burner'. ⚠[U+FE0F] CALL SPARINGLY: X charges paid credits per lookup. Not for routine enrichment of every token in a list. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

TOKENS ranked by aggregate USD held, either by tracked WHALES or by Moby USERS — never a person-vs-person ranking. Use `holder_type=whale` (default) for 'what are whales piling into'; `holder_type=user` for 'what do Moby users collectively hold most of'. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

What one TRACKED WHALE wallet currently holds. ⚠[U+FE0F] This is somebody else's portfolio, taken from Moby's public whale-tracking data. It is NOT the user's portfolio under any circumstances — for that, call `get_my_balances`. Take `wallet_address` from a WhaleWatch feed result; addresses may be returned as stable opaque references rather than raw addresses, and those references work here. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

A TRACKED WHALE's cumulative realized PnL over time — is the track record a steady climb or one lucky trade? ⚠[U+FE0F] Somebody else's equity curve, never the user's. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

A TRACKED WHALE's current holdings WITH cost basis and unrealized PnL per position. Richer than `get_whale_wallet_holdings`, which is amount + USD value only. ⚠[U+FE0F] Somebody else's positions, never the user's — for the user's own, use `get_my_balances` or `get_my_position`. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

THE RICHEST WHALE READ ON THIS SURFACE: one call combining identity, realized track record, current holdings, recent trades, and whether Moby has stopped tracking this wallet (`identity.tracking_paused_at`). Prefer this over calling `get_whale_wallet_track_record` + `get_whale_wallet_positions` separately. `windows.d7` and `windows.d30` give realized P/L, closes, win rate, avg/median hold days and the share of closes held under 24h for each window. No colour: use `read.situation` + the window stats. `include_holdings=false` returns stats only (holdings and read null) — much smaller; to rate many wallets use `get_whale_wallet_profiles`. `data_as_of` is when this was computed; a wallet Moby has SEEN but knows nothing about yet comes back with null sections rather than an error. ⚠[U+FE0F] Somebody else's profile, never the user's — for the user's own wallet use `get_my_*` tools. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Rate 10-20 key holders before a buy in one call; stats only, no holdings. Pass the `wallet_address` refs from `get_token_key_holders` (max 20). Each profile carries `windows.d7` / `windows.d30` (realized P/L, closes, win rate, median hold, short-hold share), `track_record`, `realized` and `identity`. A wallet Moby has never seen is left out — match rows on `wallet_ref`. For one wallet's holdings use `get_whale_wallet_profile`. ⚠[U+FE0F] Other people's wallets, never the user's. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The full track record behind a TRACKED WHALE: win rate, realized PnL, trade count, typical hold time, and whether Moby has finished indexing it (`backfill_state`). Judge whether a wallet seen in a WhaleWatch feed is actually good before weighting its activity. For everything in one call — including current holdings and the caller's own follow state — use `get_whale_wallet_profile` instead. ⚠[U+FE0F] Somebody else's track record, never the user's. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The biggest realised wins of one TRACKED WHALE wallet — its top closed trades by profit, at most five. Use it to judge whether a wallet seen in a WhaleWatch feed is actually good before weighting its activity. ⚠[U+FE0F] Somebody else's track record, not the user's — the user's own realised results come from `get_my_closed_positions`. An empty list means no wins data was available, not that the wallet has never won. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Moby's WhaleWatch feed: buys and sells by tracked whale wallets across the market, newest first. Filter to one token with `token_address`, to one tracked wallet with `wallet_address`, or to specific whale lists with `list_ids` (from `get_whalewatch_lists`). ⚠[U+FE0F] `wallet_address` here filters TRACKED WHALE wallets — it is not the user's wallet and cannot be used to look up the user's own trades. Use `get_my_activity` for those. For a bulk read of a whole time window, use `get_whalewatch_feed_window`. Rows sort by `timestamp` (block time, whole seconds), then `sequence` (the order Moby ingested the trades): several trades by one wallet in the same second come back in the order their position-before values chain. Every row has `wallet_list_type` (`whale`, `trader` or `kol`). SELL rows carry `held_seconds` (since the wallet's first buy of the token) and `quick_flip: true` when it sold within 15 minutes — check for it before treating that wallet's buy as conviction; buy rows leave both null. `include_context=true` adds a per-row `context` block: pnl_pct_vs_entry (the trade price vs the wallet's own average entry, as a fraction), tags (what the trade looked like, e.g. profit taking), hold_days_at_trade, share_sold_of_position, position_before_usd, entry_vwap_before, days_since_prev_trade + prev_trade_at (how long the WALLET was quiet before this trade, any token) and wallet_win_rate + wallet_realized_pnl_30d_usd (the wallet's 30-day quality). Unknown values are null — pnl_pct_vs_entry is null whenever the wallet's entry was never seen, days_since_prev_trade when Moby has no earlier trade for the wallet. Wallet quality: use get_whale_wallet_track_record(wallet_address) for a wallet's win rate and PnL. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Every tracked-whale buy and sell inside one time window (at most 48 hours), for bulk reads such as 'everything whales did in the last 6 hours'. Unlike `get_whalewatch_feed`, it returns ONE ROW PER SWAP (the plain feed repeats a swap once per whale list the wallet is on; `list_id` here is one of the matching lists), and pages with a cursor: pass `next_cursor` from the previous response as `cursor` until it is null. Rows are newest first and new trades never shift a page. Filter by side, minimum trade size, minimum market cap, trade `actions`, whale `list_ids` and `min_days_since_prev_trade` (wallets waking up after a quiet spell). A window longer than 48h is rejected. Rows sort by `timestamp` (block time, whole seconds), then `sequence` (the order Moby ingested the trades): several trades by one wallet in the same second come back in the order their position-before values chain. Every row has `wallet_list_type` (`whale`, `trader` or `kol`). SELL rows carry `held_seconds` (since the wallet's first buy of the token) and `quick_flip: true` when it sold within 15 minutes — check for it before treating that wallet's buy as conviction; buy rows leave both null. `include_context=true` adds a per-row `context` block: pnl_pct_vs_entry (the trade price vs the wallet's own average entry, as a fraction), tags (what the trade looked like, e.g. profit taking), hold_days_at_trade, share_sold_of_position, position_before_usd, entry_vwap_before, days_since_prev_trade + prev_trade_at (how long the WALLET was quiet before this trade, any token) and wallet_win_rate + wallet_realized_pnl_30d_usd (the wallet's 30-day quality). Unknown values are null — pnl_pct_vs_entry is null whenever the wallet's entry was never seen, days_since_prev_trade when Moby has no earlier trade for the wallet. Wallet quality: use get_whale_wallet_track_record(wallet_address) for a wallet's win rate and PnL. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The short, curated WhaleWatch feed the Moby app shows on its home screen — the most notable recent whale trades across the whole market, already filtered down. Use it for an open-ended 'what are whales doing right now'. For anything filtered — one token, one wallet, specific lists, a time window, or more than a handful of rows — use `get_whalewatch_feed` instead. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Same feed as `get_whalewatch_feed` but pre-filtered to KOLs — public, named crypto influencers — rather than anonymous whales. The list filter is applied server-side, so there is no `list_ids` argument. Use this when the user asks what influencers or 'the callers' are buying. For one KOL's trades, use `get_whalewatch_feed` with its `wallet_address`. `include_context=true` adds a per-row `context` block: pnl_pct_vs_entry (the trade price vs the wallet's own average entry, as a fraction), tags (what the trade looked like, e.g. profit taking), hold_days_at_trade, share_sold_of_position, position_before_usd, entry_vwap_before, days_since_prev_trade + prev_trade_at (how long the WALLET was quiet before this trade, any token) and wallet_win_rate + wallet_realized_pnl_30d_usd (the wallet's 30-day quality). Unknown values are null — pnl_pct_vs_entry is null whenever the wallet's entry was never seen, days_since_prev_trade when Moby has no earlier trade for the wallet. Wallet quality: use get_whale_wallet_track_record(wallet_address) for a wallet's win rate and PnL. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The key explaining the icons and badges attached to rows in the WhaleWatch feeds. Static reference data — call it once if you need to explain what a marker on a feed row means, and do not poll it. It contains no market data and no wallets. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The tracked-wallet lists Moby maintains (whale groups, KOL groups, proven-trader cohorts). Call this to discover valid `list_ids` for `get_whalewatch_feed`. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

One curated wallet list's rows, pre-ranked. `slug` MUST come from `get_whalewatch_wallet_lists` — an invented or stale slug is a 404, not an empty list. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The Find-wallets tab shell: a manual 'picks' strip, then one summary per curated wallet list that has rows on this chain (whale groups, KOL groups, proven-trader cohorts). Call this first to learn the valid `slug` values for `get_whalewatch_wallet_list_detail`. NOT the same lists as `get_whalewatch_lists` — that one is for filtering `get_whalewatch_feed`; this one is for browsing wallets to follow. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

The starter strategies from the Strategies section of AI Trading in the Moby app: each card's `id`, `name`, `summary`, `how_it_works`, `chips` (the editable defaults), `risk_label`, `warning` and the Moby `tools` it uses, with the user's max per trade already filled in. Use it during or after onboarding to recommend a card, and whenever the user asks what strategies there are. To match a card to the user, offer the one or two ids in `recommended_strategies` from `get_my_trading_profile` / `save_trading_profile` (majors or stocks → Large Cap Allocator, BTC <> ZEC Barbell; launches or memes → StonkFun Trend Rider, StonkFun Whale Swarm, Early Launch Hunter; mix → Smart Money Confirmed). Read each card's `summary`, `how_it_works` and `risk_label` before you recommend it, and only recommend cards this tool returned. The full prompt is NOT here: call `get_strategy(strategy_id)` for it. `app_links` are Moby app deep links to hand to the user; they open the Moby app on their phone.

Find tokens by name, symbol or contract address. Use this FIRST whenever the user names a token in words ('buy some BONK') — every other token tool needs a contract address, and searching is the only safe way to get one. Never guess a contract address: on-chain there are many impostor tokens sharing a popular symbol, and picking the wrong one loses the user's money. If several results look plausible, show them to the user and ask which they mean. `asset_class: tokenized_stock` marks tokenized equities (treat as stock proxies, not memecoins). `safety_tier`: green = verified; grey = usually fine (not scored yet or a young launchpad token, NOT a red flag — do not skip a coin for being grey); red = caution / DYOR, the only tier to treat as a warning (Moby refuses agent buys on red). This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.

Find PUBLIC whale/KOL/trader wallets by a KOL name or a whale-list brand — NOT by pasted address, and NOT the same search as `search_tokens`. Use `discover_wallets_to_follow` if you also want to know which of the results the caller already follows. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.