Skip to main content
Glama

create_topup_link

Create a checkout link for a pay-as-you-go top-up ($15 minimum; 500 credits per $1, never expire). The user opens the link and pays themselves.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "amount_usd": "<amount_usd>"
    },
    "name": "create_topup_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
amount_usdYesAmount in US dollars, at least 15.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare it is a non-read-only, non-destructive, closed-world operation, and the description adds real context beyond them: a $15 minimum, a 500-credits-per-$1 conversion, and the fact that credits never expire. It leaves out link expiry and any permission or account-state requirements, which keeps it from a 5.

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?

Two tight sentences with the core action and key economics front-loaded, and no redundant or filler wording. The pricing detail is placed after the action, which reads naturally.

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?

For a one-parameter, no-output-schema tool, the definition covers action, cost model, and credit behavior well. It does not say what the tool actually returns (presumably a URL) or whether the link expires, which are small but real gaps for the caller.

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

Parameters3/5

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

Schema coverage is 100% for the single amount_usd parameter, and the schema already states the $15 minimum. The description adds the credit conversion rate (500 credits per $1), which gives useful meaning to the amount, but the schema still carries most of the parameter documentation.

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 states a specific verb and resource, 'Create a checkout link', and scopes it to 'pay-as-you-go top-up', which is meaningfully distinct from the sibling tool 'start_plan_link'. It does not name that sibling explicitly, so the differentiation is implied rather than stated.

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?

The phrase 'The user opens the link and pays themselves' conveys the usage pattern and clarifies that the agent itself does not charge anything. However, there is no explicit guidance on when to prefer this over start_plan_link or other billing tools, nor any prerequisites or exclusions.

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