Skip to main content
Glama

list_supported_currencies

Read-only

Returns the catalog of supported blockchain assets, ticker symbols, and network standards.

USAGE GUIDELINES:

  • USE WHEN: Discovering supported coins, validating tickers, or displaying network options prior to calling quote or limit tools.

  • DO NOT USE: Calculating rates, exchange amounts, or network fees (use 'get_swap_quote' or 'get_pair_limits_and_fees').

PARAMETER INTENT & AGENT WORKFLOW:

  • Context Window Optimization: Supplying 'privacy' or 'stablecoins' filters the catalog to a specific functional class, reducing token consumption when prompting users; omitting or passing 'all' returns the full multi-chain roster.

  • Output Consumption: Tickers returned in 'currencies[].ticker' are guaranteed canonical symbols accepted by 'get_swap_quote' and 'get_pair_limits_and_fees'.

BEHAVIOR & SPECIFICATIONS:

  • In-memory response (<5ms latency) returning up to 15 non-paginated asset records with 100% availability.

  • Strictly read-only without external network dependencies.

Input Schema

NameRequiredDescriptionDefault
categoryNoOptional functional taxonomy filter to constrain output assets by blockchain architecture. Permitted values: 'all', 'privacy', 'stablecoins'.all

Output Schema

NameRequiredDescriptionDefault
totalNo
currenciesNo
routing_typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / category / description
      Previous value: -"Asset category filter: 'all' returns all assets, 'privacy' returns privacy coins (XMR, ZEC, DASH), and 'stablecoins' returns pegged assets (USDT)."New value: +"Optional functional taxonomy filter to constrain output assets by blockchain architecture. Permitted values: 'all', 'privacy', 'stablecoins'."
  2. Changed2 schema fields changed
    • addedInput schema / properties / category
      Added value: +{
      +  "default": "all",
      +  "description": "Asset category filter: 'all' returns all assets, 'privacy' returns privacy coins (XMR, ZEC, DASH), and 'stablecoins' returns pegged assets (USDT).",
      +  "enum": [
      +    "all",
      +    "privacy",
      +    "stablecoins"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / currencies / items / properties / category
      Added value: +{
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • addedOutput schema / properties / routing_type
      Added value: +{
      +  "type": "string"
      +}
  4. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses latency (<5ms), response size (up to 15 non-paginated records), availability, and lack of external network dependencies. These details are consistent with readOnlyHint=true, openWorldHint=false, and destructiveHint=false.

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

Conciseness5/5

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

The description is front-loaded with the core return value and then organized into usage, parameter intent, and behavior sections. Despite its length, each section contributes actionable guidance for selecting and invoking the tool.

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?

The tool is simple with one optional enum parameter, annotations covering safety, and an output schema. The description still provides complete usage, parameter, and behavioral context, so an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds meaningful intent: privacy and stablecoins narrow the catalog by functional class to reduce token consumption, while omitting the parameter or passing 'all' returns the full roster. It also explains that returned tickers are canonical and accepted by the quote and limit tools.

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 description uses a specific verb and resource: it returns the catalog of supported blockchain assets, ticker symbols, and network standards. It is clearly distinguishable from the quote and fee siblings, which are explicitly named as alternatives for other tasks.

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?

It gives explicit USE WHEN conditions such as discovering supported coins, validating tickers, or displaying network options before calling quote or limit tools. It also gives an explicit DO NOT USE section and routes calculation and fee tasks to get_swap_quote and get_pair_limits_and_fees.

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.