How to read this list
This is a list of the wallet tools worth giving an AI agent, meaning the operations you expose to it as tools, not a list of wallet products. The question it answers is practical: when you give an agent a wallet, which capabilities should it actually be able to invoke? The answer is a short list of include-these plus one deliberate leave-this-out, and getting it right matters because every tool you expose is something the agent can do, for better or worse.
Read it as a checklist for designing an agent's wallet surface. Include the four below as they fit your use case, and resist adding more, because a small, predictable wallet surface is both easier for the planner to use correctly and safer for you to operate. For building one of these tools concretely, see langchain-wallet-tool.
The four tools to include
The wallet tools worth including are four: pay-by-calling, read-the-spend-limit, look-up-a-transaction, and a balance or activity view. The first is essential; the rest are supporting tools you add as your use case needs. Together they cover paying, planning around budget, confirming, and reviewing, which is the full surface most agents need.
Tool 1: Pay by calling
Pay-by-calling is the essential tool. It fetches a URL and, if the response is an HTTP 402, settles the amount in USDC on Base through createX402Client and retries, returning the result. The agent calls it with a target and gets data back, having paid along the way, bounded by the wallet's spend limit.
This is the tool that makes a wallet useful, and for many agents it is the only wallet tool they need. Keep its surface to one operation, give it a target and it returns the result, because that single pay-by-calling shape covers paying data APIs, paid tools, and other agents. It is the first tool to build and the one the others support.
Tool 2: Read the spend limit
A read-the-spend-limit tool lets the agent see its own budget. It does a GET to the agent's spend-permissions endpoint and returns the limit fields, the per-transaction cap and the period allowance, so a planner can avoid attempting a call it cannot afford.
Include it when you want the agent to reason about budget before spending. It is read-only, since spend limits are set and edited in the dashboard rather than through the API, so this tool reads the budget and never changes it. The limit is enforced server-side regardless, so the read is for smarter planning, not safety. For how the limits themselves work, see how-to-set-up-agent-spending-limits.
Tool 3: Look up a transaction
A look-up-a-transaction tool lets the agent confirm a specific payment by id, using transactions.get. Given a transaction id, it returns that transaction's detail, which is useful when the agent or your code needs to verify that a particular payment went through.
Include it when the agent needs to confirm outcomes rather than just fire payments, such as checking a payment settled before proceeding. It is a narrow, read-only lookup by id, not a history feed, so it answers "did this specific payment succeed" rather than "what have I paid recently." Keep it scoped to that, and use the activity view below for the broader picture.
Tool 4: A balance or activity view
A balance or activity view lets the agent see recent payments. There is no single list-all-transactions endpoint, so you build this from your own ledger of payment.sent and payment.received webhook events, and expose a read over that ledger as the tool.
Include it when the agent benefits from seeing its recent activity, for example to summarize spending or avoid repeating a payment. Because you assemble it from the webhook stream rather than a built-in call, you control exactly what it shows, which is an advantage: you can scope it to the window and fields the agent actually needs. Keep it read-only, like the others, since the agent reviews activity rather than altering it.
Each tool's description does the work
Whichever tools you include, the description you give each one is what the planner reads to decide when to call it, so write them as carefully as the code. For pay-by-calling, say plainly that it fetches a URL and pays in USDC if the URL requires payment, and returns the body, which is usually enough for the planner to reach for it when a task needs a paid resource. For the spend-limit read, say it returns the current limit so the planner can check budget before a large call. For the transaction lookup, say it confirms whether a specific payment by id succeeded. For the activity view, say it lists recent payments over a window.
Precise descriptions keep the tools from being misused. A vague description like "interact with the wallet" leaves the planner guessing which tool applies to which moment, so it may read the limit when it should pay, or look up a transaction when it should review activity. Distinct, specific descriptions, one obvious job per tool stated in plain language, are what let a small wallet surface be used correctly. Decide deliberately whether pay-by-calling mentions cost: note it if you want the planner to weigh price, omit it if you would rather it not hesitate over routine sub-cent calls and let the spend limit be the control. The tools are small; their descriptions are where you actually shape how the agent uses its wallet, so treat the wording as part of the design rather than an afterthought.
What to leave out
Leave out an open-ended send-to-any-address tool. It is tempting to give an agent a general "send payment to this address" capability, but it is a far larger attack surface than pay-by-calling and rarely necessary, because most agent payments happen by calling a service that returns a 402. An agent with a general send tool that is prompt-injected can be steered to pay an attacker; an agent with only pay-by-calling can at worst overpay a service within its spend limit.
So the deliberate omission is part of the design, not a gap. Keep the wallet surface to pay-by-calling plus the read tools, let the server-side spend limit bound the worst case, and add an open-ended send only if you have a specific, justified need and have thought hard about the risk. For almost every agent, the four include-tools plus this one leave-out is the right surface.
How to assemble them
These tools are a pattern, not a package. You build pay-by-calling around createX402Client, the spend-limit read as a GET, the transaction lookup with transactions.get, and the activity view over your webhook ledger, all from @blockchain0x/node and @blockchain0x/x402, then wrap each as a tool in your framework.
Assemble only the ones your use case needs: every agent gets pay-by-calling, planners that reason about budget get the limit read, agents that confirm outcomes get the lookup, and agents that review activity get the view. Start with pay-by-calling alone, add the reads as the agent's behavior calls for them, and keep the open-ended send off the list. For a concrete build of the core tool, see langchain-wallet-tool; for the limits behind tool two, see how-to-set-up-agent-spending-limits. Pricing is on the pricing page.