Skip to main content
Glama

Get brokerage holdings

get_holdings
Read-onlyIdempotent

YOUR connected brokerage holdings (the API key's user — no address input, identity comes from the key): Robinhood and any other brokerage linked to Gambit through SnapTrade. Covers STOCKS/ETFs/ADRs, OPTIONS, and CRYPTO HELD AT THE BROKERAGE (an actual coin at Coinbase/Kraken/Robinhood — not COIN, BITO or MSTR, which merely track one); see get_positions / get_account_balances for Hyperliquid. Bonds, CFDs and futures are NOT reported: they are dropped rather than shown in a column that would misprice them. EACH LOT CARRIES assetClass ('equity' | 'option' | 'crypto'). OPTION ARITHMETIC IS NOT SHARE ARITHMETIC: quantity is in CONTRACTS, while marketPrice and averageCost are per SHARE (that is how a premium is quoted), and option.contractMultiplier is the shares per contract AS STATED BY THE VENUE. marketValue already has the multiplier in it. So cost basis is quantity x averageCost x contractMultiplier — never quantity x averageCost, which understates it by ~100x. contractMultiplier is NULL when the venue stated none or stated something unusable; treat null as 'cannot value this row', never as 100 (a mini covers 10, a split-adjusted contract covers whatever the adjustment made it). Options also carry option.underlyingSymbol, optionType, strikePrice and expirationDate. Rows carry listingRegion ('us' | 'non_us' | null — null means the venue did not say, NOT 'US') and isDepositaryReceipt (a US-listed foreign company; for an option this describes its UNDERLYING). Default view is compact: total value, cashUsd and buyingPowerUsd (the same numbers the Gambit web app shows: USD-labelled or unlabelled balances only, other currencies are not summed, and null — not 0 — when the total is zero or negative, so a CAD-only account or a negative margin balance reads null), each connected account (with accountId, so two accounts sharing a label stay distinguishable), and topHoldings — the 10 largest ACCOUNT-LEVEL LOTS by absolute market value PER CURRENCY (a symbol held in two accounts appears twice, each row names its account; shorts rank by exposure; amounts are never compared across currencies, there is no FX conversion) with quantity, price, market value, average cost and currency, plus holdingsCount so you know what the cap hid (meta.caps_applied is non-null only when rows were dropped). Pass view: 'full' for every lot as the raw snapshot (holdings, totalCash; no topHoldings/spotlight fields). Pass symbol (compact view only) to get activeSymbolPosition: that ticker across accounts, INCLUDING options written over it. Because shares, contracts and coins are three different units, the spotlight breaks out legs[] — one entry per assetClass, each with its own quantity/marketPrice/averageCost/marketValue — and the headline quantity, marketPrice and averageCost are NULL whenever legs has more than one entry. marketValue is the exception and stays summed across legs, because dollars add up where units do not. Null when not held. Lots with no currency code are listed last as an unranked sample (ordered by symbol, capped like any group; meta.caps_applied.top_holdings.unknown_currency_truncated says if that sample dropped rows). Sampled rows keep their nominal values with currency: null; only the SPOTLIGHT aggregate is nulled — lots spanning currencies (or with no currency code) report null marketValue/marketPrice/averageCost/currency there, and lots mixing long and short keep net quantity and net marketValue but report null marketPrice and averageCost. Tickers match exactly (BRK.B is not BRK.A; a dex: prefix like xyz:TSLA is stripped). totalValue carries currency and totalValueCaveat: currency is NULL when no account stated one — that means UNKNOWN, not USD, so do not label such a total with a currency symbol or add it to one that has a currency. totalValueCaveat names why the total is not simply the worth of every account: 'mixed_currency' (accounts disagree, or some stated none — totalValue is null), 'missing_accounts' (some accounts reported no total and are left out of it), 'holdings_only' (no account total at all, so cash is missing), 'unknown_currency' (a real figure in a unit nobody stated). holdingsDegraded: true means at least one account's positions came from a REDUCED FEED THAT CANNOT REPORT OPTIONS — the holdings are present but known to be incomplete, so say so rather than reporting an option-free account as settled; account.positionsSource names which account it was. meta.data_freshness.status is 'fresh' inside the ~60s server cache and 'stale' when a cached snapshot was served past it (brokerages sync roughly daily, so stale is usually fine for reading — not for sizing a trade). meta.degraded_reason names why the answer is EMPTY: brokerage_not_connected means the user has not linked a brokerage in Gambit (Portfolio → Connect brokerage) — an empty list is never silent. Read-only, and cannot place brokerage orders. Needs the api:portfolio scope.

Input Schema

NameRequiredDescriptionDefault
viewNocompact (default): totals + up to 10 account-level lots per currency by absolute market value + symbol spotlight; full: every lot, raw snapshot shape
symbolNocompact view only: exact ticker to spotlight, e.g. NVDA or BRK.B — aggregated across accounts as activeSymbolPosition

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description extends far beyond them: option arithmetic (contracts vs per-share pricing, contractMultiplier null handling), currency caveats (null vs USD, totalValueCaveat values), holdingsDegraded reduced-feed semantics, meta.data_freshness staleness, meta.degraded_reason, and caps_applied truncation. This is exactly the additional behavioral context the annotations cannot carry, and it is consistent with them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very long and dense, but for a tool with this many edge cases (option multipliers, currency aggregation, degraded feeds, per-cap truncation) most sentences carry load-bearing semantics rather than repetition. It is front-loaded with purpose and never buries the core statement, though the heavy capitalization and sheer volume slightly hurt scannability.

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?

There is no output schema, so the description bears the full burden of describing return shape — and it does: totalValue/currency/totalValueCaveat, accountId, topHoldings limits, activeSymbolPosition legs and null aggregation rules, holdingsDegraded, and meta flags. For a tool this complex, an agent has everything needed to interpret results 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, but the description adds real meaning beyond the schema: it explains that 'full' yields the raw snapshot (holdings/totalCash, no topHoldings/spotlight) and that symbol is compact-only, driving activeSymbolPosition with cross-leg nulling rules. That is more than a restatement of the enum/pattern.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names the exact resource and scope — 'YOUR connected brokerage holdings (the API key's user — no address input, identity comes from the key)' — plus the providers (Robinhood and any SnapTrade-linked brokerage). It explicitly distinguishes itself from get_positions/get_account_balances (Hyperliquid) and states what is excluded (bonds, CFDs, futures). An agent can tell it apart from every sibling without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes the agent to alternatives for a specific case ('see get_positions / get_account_balances for Hyperliquid') and gives condition-based selection for view:'compact' vs 'full' and the symbol spotlight. It also states the read-only constraint. It stops short of a full when-to-use map across the many siblings (e.g., when to prefer get_account_balances for cash), so it is clear but not exhaustive.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources