MoneyTools x402 agent toolkit

AI allowance setup wizard (give your AI a capped wallet)

allowance_setup

Read-onlyIdempotent

For a human who wants to give their AI agent money but does not know crypto: returns a tailored 3-step plan (zh-TW or English) - 1) create their own non-custodial AI wallet with email sign-in (Coinbase Agentic Wallet), 2) top up by region (card where supported; Taiwan: MAX/BitoPro USDC, network caveats; existing USDC) with every fee and regional limit, 3) set per-call/daily caps (wallet + optional MoneyTools gateway spend controls) and get an MCP config plus a prompt to paste into the AI, plus a dashboard link for spend and receipts. Free, unlimited, no quota used; MoneyTools never holds user funds. Lists what is unverified.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "allowance_setup"
  }
}

Input Schema

Name	Required	Description
`lang`	No	answer language; default zh for TW, else en
`client`	No	AI client to configure
`region`	No	user's country: TW (Taiwan), US or other
`hasUsdc`	No	user already holds USDC
`dailyMaxUsd`	No	daily cap in USD, default 1
`perCallMaxUsd`	No	per-call cap in USD, default 0.05

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-derivable facts: no quota consumed, MoneyTools never holds user funds, the response flags what is unverified, and it includes an MCP config, a paste-ready prompt, and a dashboard link. That is real behavioral context beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Everything stated is substantive, but it is delivered as one very long run-on sentence with deeply nested parentheticals, including a semicolon-separated region caveat mid-clause. The persona and the step list are front-loaded, yet an agent must parse heavy nesting to extract the three phases, so structure costs it a point.

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?

An output schema exists, so return-value explanation is not strictly required, and the description nonetheless summarizes the payload (plan, MCP config, prompt, dashboard link). With 6 optional, fully documented params and clear default caps, the only minor gap is what happens when client or region is omitted, which the description leaves to the 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 coverage is 100%, so baseline is 3, but the description earns above that by binding semantics to parameters: region drives top-up path (card where supported; Taiwan via MAX/BitoPro USDC with network caveats), hasUsdc selects the funding branch, and per-call/daily caps map to the wallet plus optional gateway controls. Language choice (zh-TW/English) is also contextualized rather than left as a bare enum.

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 opens with a precise verb and artifact — 'returns a tailored 3-step plan' — plus the exact audience (a non-crypto human funding an AI agent), and the enumerated steps (create wallet, top up, set caps) make the output unmistakable. It is clearly distinct from sibling planners like x402_gateway_plan or allowance_revoke_plan, which an agent can rule out from this text alone.

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?

The opening clause 'For a human who wants to give their AI agent money but does not know crypto' gives a clear triggering condition, and the 'Free, unlimited, no quota used' note tells the agent there is no cost to calling it speculatively. It does not explicitly name alternatives (e.g., allowance_revoke_plan for teardown, x402_gateway_plan for the gateway side), so the when-not guidance is only implied.

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

All MoneyTools x402 agent toolkit 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?