agentcard

add_funds

Generate a secure checkout link the user opens to add cash to their own balance (the money that funds new cards) via Apple Pay, Google Pay, or a bank transfer (ACH or wire from a US bank account), in USD. Calling this tool moves NO money and initiates NO transfer: it only prepares a single-use hosted payment page — the exact equivalent of the user clicking 'Add funds' in the dashboard. The user personally reviews, authorizes, and completes (or abandons) the payment in their own browser with their own payment method; you never see or handle payment credentials. If a one-time phone verification is needed first, this tool automatically sends the user a code and tells you where it went: ask the user for the code, call verify_phone with it, then call add_funds again.

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_cents": "<amount_cents>"
    },
    "name": "add_funds"
  }
}

Input Schema

Name	Required	Description	Default
`amount_cents`	Yes	Amount to add in cents (e.g. 5000 = $50.00). Typical range: $20.00 to $10,000.00 (2000 to 1000000 cents); the exact range depends on the active funding provider and is returned by the API when the amount is invalid.
`payment_method`	No	Payment method: apple_pay or google_pay for an instant wallet checkout (ask which one their device has; apple_pay when unknown), or ach / wire when the user wants to pay by bank transfer from their US bank account (ACH arrives in 1-3 business days, wire usually same day; minimum $10). Bank transfers need the user's identity verified first.

Output Schema

Name	Required	Description
`message`	Yes	Human-readable result or next step.
`amountUsd`	No	Amount of the created checkout in USD.
`checkoutUrl`	No	Single-use payment link to hand the user verbatim (present when a checkout was created).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 30, 2026

changedInput schema / properties / payment_method / description

Previous value: -"Payment method for the checkout: apple_pay or google_pay. Ask the user which one their device has; apple_pay only when unknown."New value: +"Payment method: apple_pay or google_pay for an instant wallet checkout (ask which one their device has; apple_pay when unknown), or ach / wire when the user wants to pay by bank transfer from their US bank account (ACH arrives in 1-3 business days, wire usually same day; minimum $10). Bank transfers need the user's identity verified first."

changedInput schema / properties / payment_method / enum

Previous value: -[
-  "apple_pay",
-  "google_pay"
-]New value: +[
+  "apple_pay",
+  "google_pay",
+  "ach",
+  "wire"
+]

Changed1 schema field changedSep 16, 2026

changedInput schema / properties / payment_method / description

Previous value: -"Payment method for the checkout. Defaults to apple_pay."New value: +"Payment method for the checkout: apple_pay or google_pay. Ask the user which one their device has; apple_pay only when unknown."

First observedJul 28, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations say readOnlyHint=false and destructiveHint=false but nothing more subtle; the description adds the crucial non-obvious behavior: no funds move server-side, the page is single-use, the user completes payment in their own browser, agent never handles credentials, and the tool may auto-trigger an SMS code. That is exactly the context an agent needs before a money-adjacent call.

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?

Front-loaded with the action first, then the no-money caveat, then user flow and verification recovery path. Every sentence earns its place, but it is long (four clauses) and the verification-recovery detail could be tightened.

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?

Output schema covers the return value (checkout link), and the description covers what an agent still needs: that nothing is charged, the page is single-use, prerequisite verification, identity requirements for bank rails, and USD-only scope. Nothing material is missing for correct invocation.

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 description coverage is 100%, so both parameters are already documented with ranges, enum values, and settlement timing. The description reinforces the payment rails and defaults but adds little syntactic or semantic detail beyond the schema, matching the baseline.

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 concrete action ("prepares a single-use hosted payment page") and the purpose ("add cash" to the user's balance that funds cards), with the supported rails enumerated. The identity of the tool is unambiguous, but no sibling is named (e.g., get_wallet_link or start_payment) to sharpen the boundary, so it stops short of the top mark.

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?

Explicitly says when this applies (user wants to add cash), what it does NOT do (moves no money, initiates no transfer), and what prerequisite path exists: send verification, call with verification_code, then call again; identity must be verified before ACH/wire. Alternatives and sequencing are spelled out rather than implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All agentcard tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?