WhereItGoes

Money in and out: USD flows, deposits, transfers, fiat

get_money_flows

Read-onlyIdempotent

Summarise money entering and leaving the portfolio, in one of four views. capital_flow: deposits and withdrawals per bucket (month by default, or week) over period (omit for all time), in USD split by asset and valued on the day they moved, oldest bucket first; moves between the user's own accounts, Earn shuffles and cancelled withdrawals are excluded, so this is capital genuinely entering or leaving. deposits: exchange deposits, newest first, with what is settled about each one's cost basis (manual_cost, transfer_id when matched to the user's own withdrawal, reconciliation classification); exchange deposits only, spam hidden. transfers: withdrawals matched to the deposit that landed on another of the user's own accounts, most recently matched first, both legs in full. fiat: per local fiat currency (e.g. VND, KRW), all-time fiat spent buying crypto and received selling it, net invested and volume-weighted rates, in that currency, not USD. period and bucket apply to capital_flow only; other views refuse them. Lists return at most 200 rows. Use for "how much did I deposit each month", "which deposits need a cost basis", "did my BTC arrive in my wallet". For single events in native units use get_movements.

Input Schema

Name	Required	Description
`view`	Yes	Which view to read: capital_flow (USD deposited and withdrawn per bucket); deposits (exchange deposits and their cost-basis status); transfers (matched moves between own accounts); fiat (fiat in and out per local currency). Each view takes only the arguments the description lists for it.
`bucket`	No	capital_flow only. Granularity of the series. Defaults to month.
`period`	No	Time window ending now: last_24h, last_7d, last_30d, last_90d, ytd (since 1 January UTC) or all. Omit for all time.
`profile`	No	Which portfolio to read, for accounts with more than one: its id, or its name (exact, case-insensitive, e.g. "Trading"). Omit to read this connection's default portfolio; every answer names the portfolio it read in `profile`. An unknown or shared name returns profile_not_found or profile_ambiguous listing the real ones, and list_profiles shows them up front.

Output Schema

Name	Required	Description
`fiat`	No	Present when view = "fiat".
`view`	No	Which view answered; its data is under the key of the same name.
`error`	No	Present ONLY when the call was refused instead of answered: upgrade_required (Pro plan needed), not_found, profile_not_found, profile_ambiguous, invalid_arguments, write_not_permitted. No data fields come with it; read `message` to the user rather than retrying the same call.
`message`	No	Plain-language explanation that accompanies `error`, `data_status` or a proposed change. Read it to the user.
`profile`	No	The portfolio these figures belong to (absent on list_profiles).
`deposits`	No	Present when view = "deposits".
`next_step`	No	What the user should do about data_status.
`transfers`	No	Present when view = "transfers".
`source_url`	No	Link to the page in the WhereItGoes app that shows this data.
`data_status`	No	Present only when the portfolio has no data yet. nothing_connected: no exchange and no wallet is connected, so empty lists and zeros mean "no data", NOT a $0 portfolio, and no data fields come with it (except on get_connections, get_alerts, get_target_allocation and list_profiles, which also answer). Send the user to next_step. syncing: a source is connected but its first sync is still running, so figures are partial and not final.
`upgrade_url`	No	Where the user can upgrade, on an upgrade_required refusal.
`capital_flow`	No	Present when view = "capital_flow".
`stock_assets`	No	Present when the answer mentions Binance Stocks shares (EQ_<ticker>): they are US stocks, not crypto.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 28, 2026

addedOutput schema / properties / data_status

Added value: +{
+  "description": "Present only when the portfolio has no data yet. nothing_connected: no exchange and no wallet is connected, so empty lists and zeros mean \"no data\", NOT a $0 portfolio, and no data fields come with it (except on get_connections, get_alerts, get_target_allocation and list_profiles, which also answer). Send the user to next_step. syncing: a source is connected but its first sync is still running, so figures are partial and not final.",
+  "enum": [
+    "nothing_connected",
+    "syncing"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / message / description

Previous value: -"Plain-language explanation that accompanies `error` or a proposed change."New value: +"Plain-language explanation that accompanies `error`, `data_status` or a proposed change. Read it to the user."

addedOutput schema / properties / next_step

Added value: +{
+  "additionalProperties": true,
+  "description": "What the user should do about data_status.",
+  "properties": {
+    "action": {
+      "enum": [
+        "connect_a_source",
+        "wait_for_first_sync"
+      ],
+      "type": "string"
+    },
+    "add_exchange_url": {
+      "description": "App page to connect an exchange with a read-only API key.",
+      "type": "string"
+    },
+    "add_wallet_url": {
+      "description": "App page to add a wallet address to watch.",
+      "type": "string"
+    },
+    "settings_url": {
+      "type": "string"
+    },
+    "sync_status_url": {
+      "description": "App page showing sync progress.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "action"
+  ],
+  "type": "object"
+}

AddedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the read-only/idempotent profile, but the description adds substantive behavior: the exclusion rules for internal moves, Earn shuffles and cancelled withdrawals, spam hiding on deposits, a 200-row cap, and ordering per view (oldest bucket first, newest first, most recently matched first). That is exactly the context annotations cannot convey.

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?

Front-loaded with the one-line purpose, then organized view-by-view, with the fallback to get_movements last. The view paragraphs are dense run-on clauses, but nearly every clause carries operational meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return shapes, and it doesn't waste space doing so. It covers view selection, per-view parameters, exclusions, ordering, row caps, and the sibling escape hatch – everything needed to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description still adds value by tying each parameter to a view ('period and bucket apply to capital_flow only') and restating the all-time default for an omitted period. It does not add much on profile beyond what the schema already says.

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?

Opens with a specific verb and resource ('Summarise money entering and leaving the portfolio') and then enumerates all four views with their exact scope. It distinguishes itself from the closest sibling by naming get_movements for single events in native units.

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 concrete routing examples ('how much did I deposit each month', 'which deposits need a cost basis', 'did my BTC arrive in my wallet') and an explicit alternative for a different need. It also states the constraint that period and bucket apply only to capital_flow and are refused by other views.

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

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