Skip to main content
Glama

Get deposit addresses

get_deposit_addresses
Read-only

Read-only. The addresses to send funds TO in order to FUND this account, one per (asset, chain) pair. These are Skipo-owned addresses that credit the balance — the OPPOSITE direction from get_contacts, which lists the external destinations money can be withdrawn to. Do not confuse the two: sending to a contact address does not fund the account.

Each entry has assetSymbol, networkId, networkName, address, tag, tagRequired, tagType and tagLabel. Join to an asset or a movement on networkId — the same key everywhere.

⚠️ FOUR ways a deposit is lost, all stated here rather than left to be inferred. FIRST: an address is only valid on the networkId it is listed under. Chains share address formats — every EVM chain does — so the same string can appear under several, and funds sent over a chain Skipo does not sweep do not arrive. SECOND: when tagRequired is true the tag is MANDATORY, because Skipo shares one address across accounts on those chains and the tag is the only thing identifying this one. tagType says which word the chain uses (MEMO or DESTINATION_TAG) as a machine key; tagLabel is the display text. Branch on tagRequired, never on tag !== null — most chains have no tag — and never on tagLabel, which can be null while a tag is still required.

THIRD: an EVM address is shared by EVERY token on that chain, so sending a different asset to the address listed for this one parks the funds for manual review. Send only the exact assetSymbol on the row, and if an expected pair is absent do NOT use a neighbouring row address. FOURTH: a deposit below the asset minimumDeposit is NOT rejected, returned or queued — it is swept to a Skipo internal account, producing no deposit row, no webhook and no error. Read minimumDeposit from get_assets before advising any amount, and warn against dust as a connectivity test. All four failures are silent: there is no error response for any of them, and recovery is a manual support case.

Addresses are stable — Skipo does not rotate or retire them — and reading this never mints a new one, so re-reading is free. Identify a row by the PAIR (assetSymbol, networkId), not by the address string, which is not unique across chains. A pair with no address yet is ABSENT rather than listed empty. Fiat has no chain and is never listed: asking for CLP returns an empty list, not an error. Amounts are not here: minimumDeposit is on get_assets.

⚠️ ONLY assets the account has ADDED are listed, and this is the most common reason a user says an address is "missing". Skipo pre-provisions an address for effectively the whole catalogue before anyone asks for it, so an address existing does not mean the asset is in use. An asset that has not been added returns an EMPTY list — including when it is named explicitly. Do NOT report that as "you have no address" or as an error: the address already exists and is unchanged. The fix is to add the asset in the Skipo app, or open the deposit screen and select it, after which it appears here on the next call. This is the same set get_balances returns.

Returns a bare list, not paginated.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_deposit_addresses"
  }
}

Input Schema

NameRequiredDescriptionDefault
asset_symbolNoRestrict to one asset. Omit for every asset the account can deposit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes well beyond them: addresses are stable and never rotated, reading never mints a new one, and four distinct silent-failure modes produce no error and require manual support recovery. It also discloses that only added assets are listed and that fiat returns an empty list rather than an error — rich context the 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?

The critical orientation sentence is front-loaded and the numbered failure modes are clearly enumerated rather than buried in prose. It is long for a single-parameter read tool and repeats a few points (minimumDeposit and the silent-failure warning appear twice), but the density is justified by the number of distinct footguns.

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 carries the return-shape burden and does so by enumerating every entry field (assetSymbol, networkId, networkName, address, tag, tagRequired, tagType, tagLabel) and the join key. It also closes the obvious follow-up gaps: no pagination, absent vs empty pair, and where amounts live.

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 asset_symbol parameter is already documented, giving a baseline of 3. The description adds real semantics beyond the schema: a pair is identified by (assetSymbol, networkId) not by the address string, and an explicitly named asset that has not been added returns an empty list rather than an error.

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 ('addresses to send funds TO in order to FUND this account, one per (asset, chain) pair') and explicitly contrasts with the sibling get_contacts by direction. An agent can distinguish funding addresses from withdrawal destinations without opening either schema.

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 explicit when-to-use and when-not-to-use: use this for funding addresses, do not confuse with get_contacts, and read minimumDeposit from get_assets before advising an amount. It also names the prerequisite action (add the asset in the app) when the list comes back empty.

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