Skip to main content
Glama

get_account_balance

Read-onlyIdempotent

Get account balance

Returns the Laso account balance and total deposits for the authenticated user, plus the managed agent wallet's balance under agent_wallet so both are visible in one call.

These are two separate balances. The account balance is a ledger held by Laso. The agent wallet is an on-chain wallet that holds USDC. A paid request moves USDC from the wallet to Laso, so it is recorded on the account balance as a deposit and then debited by the purchase. total_deposits therefore includes purchases paid from the agent wallet, and a balance of 0 after a purchase is expected. Funds still held are agent_wallet.balance_usdc plus balance.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
noteNoPlain-language explanation of how the account balance and the agent wallet relate.
balanceNoLaso account balance in USD. This is a ledger held by Laso and is what `/withdraw` draws on. It is not the agent wallet's on-chain balance; see `agent_wallet`.
user_idNoThe user's ID (lowercase wallet address)
agent_walletNoThe caller's managed agent wallet: separate on-chain USDC on Solana and Base, with `balance_usdc` the total. Not part of the account balance. Spend it through `agentX402Pay` and move it with `agentWalletTransfer`.
balance_typeNoNames what `balance` measures: the Laso account balance, not the agent wallet. One of: account_balance.
total_depositsNoTotal lifetime USD credited to the account balance. Includes every paid request settled from the agent wallet, because each one arrives as a deposit before the purchase debits it. It is not a measure of money received from outside.
created_timestampNo
created_timestamp_readableNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / agent_wallet / description
      Previous value: -"The caller's managed agent wallet: a separate on-chain Solana wallet holding USDC. Not part of the account balance. Spend it through `agentX402Pay` and move it with `agentWalletTransfer`."New value: +"The caller's managed agent wallet: separate on-chain USDC on Solana and Base, with `balance_usdc` the total. Not part of the account balance. Spend it through `agentX402Pay` and move it with `agentWalletTransfer`."
  2. Changed1 schema field changed
    • changedOutput schema / properties / agent_wallet / description
      Previous value: -"The caller's managed agent wallet: separate on-chain USDC on Solana and Base, with `balance_usdc` the total. Not part of the account balance. Spend it through `agentX402Pay` and move it with `agentWalletTransfer`."New value: +"The caller's managed agent wallet: a separate on-chain Solana wallet holding USDC. Not part of the account balance. Spend it through `agentX402Pay` and move it with `agentWalletTransfer`."
  3. Changed5 schema fields changed
    • addedOutput schema / properties / agent_wallet
      Added value: +{
      +  "description": "The caller's managed agent wallet: separate on-chain USDC on Solana and Base, with `balance_usdc` the total. Not part of the account balance. Spend it through `agentX402Pay` and move it with `agentWalletTransfer`.",
      +  "properties": {
      +    "balance_usdc": {
      +      "description": "USDC held on-chain by the agent wallet. The same figure `getAgentWallet` reports.",
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "has_wallet": {
      +      "description": "False for wallet-native accounts and managed accounts with no wallet provisioned yet.",
      +      "type": [
      +        "boolean",
      +        "null"
      +      ]
      +    },
      +    "wallet_address": {
      +      "description": "The wallet's Solana address, or null when `has_wallet` is false.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / balance / description
      Previous value: -"Current available balance in USD"New value: +"Laso account balance in USD. This is a ledger held by Laso and is what `/withdraw` draws on. It is not the agent wallet's on-chain balance; see `agent_wallet`."
    • addedOutput schema / properties / balance_type
      Added value: +{
      +  "description": "Names what `balance` measures: the Laso account balance, not the agent wallet. One of: account_balance.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / note
      Added value: +{
      +  "description": "Plain-language explanation of how the account balance and the agent wallet relate.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / total_deposits / description
      Previous value: -"Total lifetime deposits in USD"New value: +"Total lifetime USD credited to the account balance. Includes every paid request settled from the agent wallet, because each one arrives as a deposit before the purchase debits it. It is not a measure of money received from outside."
  4. Changed2 schema fields changed
    • removedInput schema / properties / auth_token
      Removed value: -{
      -  "description": "Laso credential. Only if the MCP connection has no Authorization header.",
      -  "type": "string"
      -}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "description": "Account balance information.",
      +  "properties": {
      +    "balance": {
      +      "description": "Current available balance in USD",
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "created_timestamp": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "created_timestamp_readable": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "total_deposits": {
      +      "description": "Total lifetime deposits in USD",
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "user_id": {
      +      "description": "The user's ID (lowercase wallet address)",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "type": "object"
      +}
  5. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "description": "Account balance information.",
      -  "properties": {
      -    "balance": {
      -      "description": "Current available balance in USD",
      -      "type": [
      -        "number",
      -        "null"
      -      ]
      -    },
      -    "created_timestamp": {
      -      "type": [
      -        "number",
      -        "null"
      -      ]
      -    },
      -    "created_timestamp_readable": {
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    },
      -    "total_deposits": {
      -      "description": "Total lifetime deposits in USD",
      -      "type": [
      -        "number",
      -        "null"
      -      ]
      -    },
      -    "user_id": {
      -      "description": "The user's ID (lowercase wallet address)",
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    }
      -  },
      -  "type": "object"
      -}New value: +null
  6. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), yet the description adds substantial business-logic context beyond them: the ledger-vs-on-chain distinction, the USDC flow that makes a paid request appear as a deposit then a debit, and the expectation that `balance` can legitimately be 0 after a purchase. This is exactly the kind of non-obvious behavior an agent needs to interpret results correctly.

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 summary line followed by two paragraphs of interpretation; the opening line restates the title verbatim, which is mild waste. The remaining prose is dense but every sentence carries real semantics, so length is largely justified by the two-balance model.

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?

An output schema already documents the return structure, and the description goes further by explaining what the returned numbers mean and how they move. For a zero-parameter read tool with full annotation coverage, nothing an agent needs to call or interpret it is missing.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-argument tool.

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

Purpose5/5

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

States a specific verb and resource ('Get account balance') and immediately specifies exactly what is returned: the Laso account balance, total deposits, and the managed agent wallet balance under `agent_wallet`. It also distinguishes this tool's dual-balance scope from the single-wallet view implied by the sibling `get_agent_wallet`, so an agent can differentiate 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 Guidelines3/5

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

Usage is only implied: the phrase 'so both are visible in one call' and the note that 'a `balance` of 0 after a purchase is expected' tell the agent when the returned values matter, but there is no explicit when-to-use, when-not-to-use, or named alternative. Adequate but leaves selection logic to inference.

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