QuickBuild token-saver tools + x402

Base wallet balances (ETH + tokens)

base_wallet_balances

Read-only

[PAID $0.002 USDC per call via x402 on Base; errors are free] Balances of one address on Base mainnet in a single call: native ETH, the well-known tokens USDC, USDT, USDbC, DAI, WETH, cbETH, wstETH, AERO (non-zero only, or all with includeZero=true), plus up to 10 extra ERC-20 contracts you pass in tokens (symbol/name/decimals read on-chain). Also an always-present usdc block (balance + USD, also when 0), txCount (= nonce, transactions sent), account type (EOA, EIP-7702 delegated EOA, or contract) and a USD total for ETH/WETH (Chainlink) and stablecoins. Read live from public Base RPC via Multicall3; cached 10 s. All params optional: defaults to a well-known public address. Invalid input = 400, never charged.

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": "base_wallet_balances"
  }
}

Input Schema

Name	Required	Description
`tokens`	No	Optional comma-separated extra ERC-20 contract addresses on Base (max 10).
`address`	No	Base address (0x + 40 hex). Optional: defaults to 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 (vitalik.eth).
`includeZero`	No	Also list well-known tokens with zero balance (default false).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover read-only/non-destructive, and the description adds substantial context beyond them: $0.002 USDC per call via x402 with free errors, 10-second cache, live Multicall3 reads from public RPC, and 400-not-charged on invalid input. That is exactly the cost/latency/failure behavior an agent needs before invoking.

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?

Cost/error note is front-loaded in brackets and purpose follows immediately, so the important facts lead. It is a dense run-on paragraph, however, cramming pricing, token list, return blocks, caching, and error codes into one block without structure.

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?

With no output schema, the description carries the burden of describing returns and does so thoroughly (per-token balances, usdc + USD, txCount as nonce, account type taxonomy, USD totals and price sources). Combined with the disclosed cost, caching, and error semantics, an agent has everything needed to call and interpret it.

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 the baseline is 3; the description still adds meaning by explaining that default well-known tokens are non-zero only, that symbols/name/decimals for `tokens` are read on-chain, and that the `usdc` block is always present even at zero. It restates the max-10 and default-address facts already in the schema, which caps it below 5.

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 verb and resource ('Balances of one address on Base mainnet in a single call') and enumerates exactly what comes back: native ETH, named well-known tokens, extra ERC-20s, usdc block, txCount, account type, USD totals. An agent can distinguish this from base_snapshot or address_brief without opening a schema.

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 description gives in-tool conditions (includeZero=true to see zero balances, up to 10 extra contracts via tokens, all params optional with a public default address), which is useful. But it never routes the agent against the many siblings that overlap (base_snapshot, address_brief, base_token_batch, sol_wallet), so when-to-use-this-vs-alternatives is left to inference.

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

All QuickBuild token-saver tools + x402 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?