Skip to main content
Glama

Fund XRPL Wallet via Coinbase

fund_xrpl_wallet_via_coinbase
Destructive

Buy XRP on Coinbase and withdraw it to an XRPL address in one call.

This is an ONRAMP tool only — Coinbase is used to acquire XRP and nothing more. All escrow creation and settlement happens on XRPL, not on Coinbase. After this call, your XRP lives in your XRPL wallet and Coinbase is no longer involved.

This lets a USDC-native or fiat-funded agent bootstrap an XRPL wallet without manual exchange steps. Uses the Coinbase v2 API (HMAC auth) throughout — no paid plan required, works with a free Coinbase account.

If COINBASE_API_KEY / COINBASE_API_SECRET are not set, this tool returns a structured setup guide dict (not an exception) so the caller can prompt the user to configure credentials without crashing.

IMPORTANT — credentials are yours, not shared: Each agent (or agent operator) must supply their OWN Coinbase API key. Never use someone else's key — it would charge their account, not yours. The AgentTrust MCP server itself holds no Coinbase credentials. Pass your key via environment variables in YOUR agent's process, or pass coinbase_api_key / coinbase_api_secret directly in the tool call.

One-time human setup (takes ~5 minutes):

  1. Create a free account at coinbase.com and complete KYC (passport/ID)

  2. Go to coinbase.com/settings/api → New API Key

  3. Grant: wallet:accounts:read, wallet:buys:create, wallet:transactions:send

  4. Set COINBASE_API_KEY and COINBASE_API_SECRET in your agent's environment

After setup, this tool is fully autonomous — no human needed per transaction.

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": {
      "xrpl_address": "<xrpl_address>"
    },
    "name": "fund_xrpl_wallet_via_coinbase"
  }
}

Input Schema

NameRequiredDescriptionDefault
usd_amountNoUSD to spend (default $3 — covers 1 XRP reserve + Coinbase fees + XRP price variance buffer)
xrpl_addressYesDestination XRPL address (your wallet's public address; get it from get_wallet_setup_guide() or create_agent_wallet())
coinbase_api_keyNoYour Coinbase API key (falls back to COINBASE_API_KEY env var)
coinbase_api_secretNoYour Coinbase API secret (falls back to COINBASE_API_SECRET env var)

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / xrpl_address / description
      Previous value: -"Destination XRPL address (from create_agent_wallet)"New value: +"Destination XRPL address (your wallet's public address; get it from get_wallet_setup_guide() or create_agent_wallet())"
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructive=true, non-idempotent and openWorld, and the description adds substantial context beyond them: real money is spent from the caller's own Coinbase account, HMAC v2 auth is used, no paid plan is needed, required OAuth scopes are listed, and — importantly — missing credentials yield a structured setup-guide dict rather than an exception. It also warns that using another party's key charges their account, which is precisely the risk profile an agent needs for a destructive tool.

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?

Core purpose and the onramp-only scope are front-loaded, which is the right ordering. It is somewhat long, with mild redundancy ('Coinbase is used to acquire XRP and nothing more' / 'Coinbase is no longer involved'), but the numbered five-minute setup checklist earns its space for a credentialed onramp 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?

For a 4-parameter tool with an output schema present, the description covers everything an agent needs: prerequisites, credential sourcing, API scopes, the non-exception failure mode, cost implications, and post-call state. Return-value detail is correctly left to the output schema.

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 description coverage is 100%, so baseline is 3; the description goes further by explaining the credential parameters' ownership semantics (never use someone else's key) and that keys can be supplied either via env vars or directly in the call. It does not add much on usd_amount beyond what the schema's default rationale already says.

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?

States a specific compound action — buy XRP on Coinbase and withdraw it to an XRPL address — in one sentence, and immediately scopes it as an ONRAMP-only tool distinct from escrow/settlement flows. An agent can distinguish it from siblings like create_agent_wallet, get_wallet_setup_guide, or create_escrow_vault without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear use case ('lets a USDC-native or fiat-funded agent bootstrap an XRPL wallet without manual exchange steps') and an explicit boundary ('Coinbase is used to acquire XRP and nothing more; escrow creation and settlement happen on XRPL'). It also states the prerequisite path (credentials must be set) and what happens otherwise. It does not explicitly name a sibling alternative for agents who already hold XRP, so it falls short of a full when/when-not routing.

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.