Skip to main content
Glama

get_treasuries

Read-onlyIdempotent

DeFi protocol treasury holdings -- how much a protocol holds in its own treasury, split into its own token, stablecoins, majors and others, largest treasury first. Pass protocol (name, slug or CoinGecko id; the '(treasury)' suffix is optional) or symbol to look one up. Results are one page: limit 1-100 (default 25), offset 0-10000; pass next_offset to get the next page. Use it when the user asks about protocol treasuries, DAO holdings or protocol-owned liquidity.

[Access: pay 0.01 USDC via x402 (PAYMENT-SIGNATURE header) OR authenticate with an API key. An x402-capable client will auto-pay; API-key clients pay nothing per call.]

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_treasuries"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum results.
offsetNoPagination offset in the result units documented by the tool; zero starts the first page.
symbolNoAsset symbol, e.g. BTC or ETH.
protocolNoProtocol or token name, DefiLlama slug or CoinGecko id, case-insensitive exact match.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
      +  "default": 25,
      +  "description": "Maximum results.",
      +  "type": "integer"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Pagination offset in the result units documented by the tool; zero starts the first page.",
      +  "type": "integer"
      +}
    • addedInput schema / properties / protocol
      Added value: +{
      +  "description": "Protocol or token name, DefiLlama slug or CoinGecko id, case-insensitive exact match.",
      +  "type": "string"
      +}
    • addedInput schema / properties / symbol
      Added value: +{
      +  "description": "Asset symbol, e.g. BTC or ETH.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot carry: a 0.01 USDC x402 payment (or API-key auth with no per-call cost), a single-page result model with limit/offset bounds and a next_offset continuation, and the largest-first ordering.

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?

Two tight paragraphs: what the data is and how to identify/slice it first, access and payment terms bracketed at the end. Nearly every sentence carries information; only the pagination bounds slightly duplicate the schema.

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

Completeness4/5

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

All four optional parameters, the lookup formats, the result breakdown, sort order and paging are covered, and with no output schema the description still sketches the return shape (categories and ordering). The only remaining gap is what the treasury figures are denominated in and whether results include chains, minor for a read-only list tool.

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 earns more by clarifying that the protocol value accepts a name, slug or CoinGecko id and that the '(treasury)' suffix is optional — the schema mentions only slug/CoinGecko id and says nothing about the suffix. It also restates the numeric bounds and the next_offset paging convention beyond the schema's generic offset text.

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

Purpose4/5

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

The description opens with a specific verb-and-resource statement: treasury holdings for a DeFi protocol, broken into own token, stablecoins, majors and others, sorted largest first. That breakdown conceptually separates it from the TVL tools in the sibling list (get_protocol_tvl, get_chain_tvl), though no sibling is named explicitly, which keeps it just short of a 5.

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 gives a clear trigger: 'Use it when the user asks about protocol treasuries, DAO holdings or protocol-owned liquidity,' and explains how to identify the subject via protocol or symbol. It stops short of explicit exclusions, e.g. telling the agent to prefer get_protocol_tvl when the user wants total value locked rather than treasury composition.

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.