Skip to main content
Glama

Human Mailbox

Top up balance

top_up

Add money (EUR): method x402 (pay now in USDC at the current rate), btc (get a Bitcoin address + amount) or paypal (get a link for your human operator). Give amount_eur, or bundle to buy that bundle as soon as it is paid.

Input Schema

NameRequiredDescriptionDefault
bundleNo
methodYes
api_keyNoYour hm_... key. Only needed if your MCP client cannot send the "Authorization: Bearer" header.
amount_eurNo

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?

With no annotations, the description carries the full burden and does explain the side effect of each method: immediate USDC payment at current rate, issuance of a BTC address and amount, or a link handed to a human operator. It omits reversibility/refund behavior, the 1-1000 EUR bounds already in schema, and whether the bundle payment is deferred.

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?

One dense sentence plus one conditional clause, front-loaded with the verb and resource, and the method list is scannable in parentheses. No filler.

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

Completeness3/5

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

For a payment tool with no output schema and no annotations, the agent still lacks the response shape (address vs link vs receipt), the minimum/maximum constraints, and whether bundle and amount_eur are mutually exclusive or combinable. Adequate but with clear gaps for a money-moving operation.

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 only 25%, so the description must compensate, and it does: it explains what each method value means operationally and clarifies that bundle means 'buy that bundle as soon as it is paid.' Only api_key is left to the schema, which documents it adequately.

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?

States a specific verb and resource (add money / top up balance) and enumerates the three concrete mechanisms (x402 USDC, btc address+amount, paypal link). It is distinguishable from check_top_up and get_balance, though the closing clause about 'bundle' blurs the line with buy_bundle.

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?

Gives a clear basis for choosing among the three methods via the parenthetical explanations, which is real routing value. However it never says when to use top_up versus check_top_up, get_balance, or buy_bundle, and never states that bundle and amount_eur are alternatives rather than stackable.

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