Skip to main content
Glama

Get portfolio value

get_portfolio_value
Read-onlyIdempotent

Total USD value across every wallet address you track: wallet token balances plus DeFi positions (lending, staking, LPs, rewards — net of debt), with the split as walletValue + defiValue = totalValue, overall and per address and chain. Receipt and LP tokens a DeFi position already counts are not also counted as wallet balances. Rows cover the chains each address holds something on. A row whose walletValue is null is a chain where the address holds DeFi positions but whose wallet balances the connector does not read. A row with an error could not be read at all. Across every tracked wallet, each wallet is read from its latest stored portfolio sample (the Sentio API samples tracked wallets hourly): such an entry says source: "sample" and gives its time as asOf. A wallet without a recent sample, and any Sui wallet (its stored history covers fewer protocols), is scanned live (source: "live"). For one wallet's current state, ask for it by address. An aggregate answers within about 40 s: a wallet it could not re-read in time is answered from its last live read of the past 15 minutes when there is one (asOf says when), and otherwise comes back with pending: true, partial: true and no figures, and the total is marked partial. Its scan keeps running, so asking again in a minute usually returns it — do not report a pending wallet as empty. The Sentio portfolio API answers within about 25 s: when it stops a scan before reading everything, or a chain or protocol read fails (for example the wallet token-balance provider), the result (and each affected entry) carries partial: true and missing lists the chains and protocols not read. Its values are then incomplete and can be too low or too high (an unread position is left out; a debt left unpriced overstates a net value) — say so, and retry later or ask for fewer chains rather than reporting them as complete.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
partialNo
addressesYes
defiValueYes
totalValueYes
walletValueYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedOutput schema / properties / addresses / items / properties / asOf
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • addedOutput schema / properties / addresses / items / properties / missing
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "chain": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      },
      +      "protocolId": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      }
      +    },
      +    "required": [
      +      "chain",
      +      "protocolId"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / addresses / items / properties / partial
      Added value: +{
      +  "const": true,
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / addresses / items / properties / pending
      Added value: +{
      +  "const": true,
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / addresses / items / properties / source
      Added value: +{
      +  "enum": [
      +    "sample",
      +    "live"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / partial
      Added value: +{
      +  "const": true,
      +  "type": "boolean"
      +}
  2. Changed6 schema fields changed
    • addedOutput schema / properties / addresses / items / properties / defiValue
      Added value: +{
      +  "type": "number"
      +}
    • addedOutput schema / properties / addresses / items / properties / walletValue
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • changedOutput schema / properties / addresses / items / required
      Previous value: -[
      -  "chain",
      -  "chainName",
      -  "address",
      -  "totalValue",
      -  "tokens"
      -]New value: +[
      +  "chain",
      +  "chainName",
      +  "address",
      +  "totalValue",
      +  "tokens",
      +  "walletValue",
      +  "defiValue"
      +]
    • addedOutput schema / properties / defiValue
      Added value: +{
      +  "type": "number"
      +}
    • addedOutput schema / properties / walletValue
      Added value: +{
      +  "type": "number"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "totalValue",
      -  "addresses"
      -]New value: +[
      +  "totalValue",
      +  "walletValue",
      +  "defiValue",
      +  "addresses"
      +]
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare read-only, open-world, idempotent, non-destructive behavior. The description goes far beyond that, disclosing hourly Sentio sampling, live-scan fallback, ~40s aggregate and ~25s API timing, partial/pending semantics, asOf/source fields, and how missing or errored entries should be interpreted.

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

Conciseness3/5

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

The description is front-loaded and every sentence conveys a behavioral trait, but it is a single dense paragraph that runs long for a zero-parameter tool with an output schema. It could be shortened or split into sections without losing 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?

Given the tool's output complexity — aggregate totals, per-address and per-chain rows, partial flags, sampling behavior, and error handling — the description is complete enough for an agent to interpret results and handle pending or partial responses. The output schema exists, so the return-value detail is supplementary rather than mandatory.

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?

With zero input parameters, there is no parameter surface to document, so the baseline is 4. The description appropriately spends no time on parameter syntax, instead directing single-wallet use to a different call.

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: 'Total USD value across every wallet address you track', and immediately defines what is included (wallet balances plus DeFi positions, net of debt). It also distinguishes the aggregate scope from a single-wallet query ('For one wallet's current state, ask for it by address'), so an agent can separate it from per-address siblings.

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?

Provides clear context for aggregate portfolio retrieval and explicitly routes single-wallet current-state requests to an address-based query. It does not name sibling tools such as get_wallet_balances or get_defi_positions, and the advice to 'ask for fewer chains' is not actionable because this tool has no chain parameter.

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.