Skip to main content
Glama

roamzy_payment_options

Read-onlyIdempotent

⚠️ MANDATORY before roamzy_create_order whenever the user has NOT explicitly chosen a stablecoin + network. Returns the list of stablecoin/network combinations currently enabled in the Roamzy NowPayments account (e.g. USDT on TRON, USDC on Solana, etc.) — pulled live from NowPayments /v1/merchant/coins with 1h cache. Each entry includes code (pass as pay_currency to create_order), human-readable display, fees_hint, and a recommended flag. After calling this tool, ASK the user in chat which option they want — NEVER silently default to usdttrc20. Recommended UX: present the 3-5 most relevant options as a short bulleted list, mention fees_hint as a one-line aside, then ask the user which stablecoin and network they want to pay with. Only after the user picks should you call roamzy_create_order with the matching code as pay_currency.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
optionsYes
api_versionNo
minimum_usdtNoHard floor on a top-up.
agent_guidanceNo
price_currencyNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "agent_guidance": {
      +      "type": "string"
      +    },
      +    "api_version": {
      +      "type": "string"
      +    },
      +    "minimum_usdt": {
      +      "description": "Hard floor on a top-up.",
      +      "type": "number"
      +    },
      +    "note": {
      +      "type": "string"
      +    },
      +    "options": {
      +      "items": {
      +        "properties": {
      +          "code": {
      +            "description": "Pass verbatim as pay_currency to roamzy_create_order.",
      +            "type": "string"
      +          },
      +          "display": {
      +            "description": "Ready-to-show label.",
      +            "type": "string"
      +          },
      +          "fees_hint": {
      +            "type": "string"
      +          },
      +          "network": {
      +            "type": "string"
      +          },
      +          "network_short": {
      +            "type": "string"
      +          },
      +          "recommended": {
      +            "type": "boolean"
      +          },
      +          "stablecoin": {
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "price_currency": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "options"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=true, idempotentHint=true), the description adds valuable context: data is pulled live from NowPayments with a 1h cache, each entry includes specific fields, and the tool must be followed by a user prompt. It also warns against silently defaulting to usdttrc20, a behavioral pitfall. No contradiction with annotations.

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 dense but every sentence contributes. It front-loads the critical mandatory warning, then explains the source, fields, and required follow-up action. The structure guides the agent step-by-step without redundant fluff.

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 description fully covers the tool's role in the workflow, its live data source, output structure, and the necessary user interaction. Given that it is a prerequisite to a payment order, the context is complete and leaves no ambiguity. The existing output schema covers return values, so the description appropriately focuses on usage.

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?

The tool has no parameters, so the baseline is 4. The description goes beyond baseline by explaining the meaning of output fields (code, display, fees_hint, recommended) and how to use the `code` as pay_currency for roamzy_create_order. This adds significant semantic value for the agent.

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 clearly states the tool returns the list of stablecoin/network combinations currently enabled in the Roamzy NowPayments account. It uses a specific verb ('Returns') and resource, and distinguishes itself from siblings by explicitly positioning it as a mandatory precursor to roamzy_create_order when the user has not chosen a stablecoin+network.

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?

The description explicitly states when to use the tool: 'MANDATORY before roamzy_create_order whenever the user has NOT explicitly chosen a stablecoin + network.' It further provides clear behavioral guidance: never silently default, ask the user, and recommended UX for presenting options. This fully explains when and how to use the tool versus alternatives.

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.