It is an MCP server that lets an agent manage a non-custodial USDG wallet on Robinhood Chain and pay x402/402-Payment-Required APIs automatically.
get_address – Print (or create on first run) the wallet address to fund with USDG.
get_balance – Read the wallet’s ETH and USDG balances.
pay – Call an x402 endpoint, read the 402 challenge, and pay in USDG if needed; supports GET/POST, JSON bodies, and budget caps.
history – Show recent payments from the local log (default 10, up to 50).
create_session – Mint a scoped session with allowed hosts, total budget, per-call cap, and TTL.
list_sessions – Show every session, its spending, and whether it is still live.
revoke_session – Kill a session so it stops paying on its next call.
Sessions restrict what hosts an agent can pay and cannot widen the wallet’s own caps.
The wallet is non-custodial: the key stays on the machine, never leaves it, and payments settle through the facilitator without needing ETH.
Provides an on-chain wallet for agents to hold USDG and pay x402 endpoints on Robinhood Chain, with tools for checking balances, sending payments, and reviewing transaction history.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@aeron-wallet Pay the x402 request to inference.aeron.sh with the DeepSeek chat completion body."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A non-custodial wallet for agents. It holds USDG on Robinhood Chain and pays
402 Payment Required responses on its own, so an agent can call a metered API
without a card, an account, or a human in the loop.
Ships two ways: a CLI, and an MCP server for Claude and other MCP clients.
npx -y aeron-wallet addressThat prints your wallet address and creates a key on first run. Send USDG to that address, then pay for a call:
npx -y aeron-wallet pay https://inference.aeron.sh/v1/chat/completions \
'{"model":"deepseek/deepseek-chat","messages":[{"role":"user","content":"hi"}]}'The wallet reads the 402 challenge, checks it against your budget caps, signs an EIP-3009 transfer, and retries the request with the payment attached. You do not need ETH: the facilitator relays the transaction and pays gas.
Related MCP server: PipRail
Command | What it does |
| Print the wallet address. Creates the key if none exists. |
| ETH and USDG balances, read from chain. |
| Call an x402 endpoint, paying if it answers 402. POST unless told otherwise. |
| The last 10 payments, from the local log. |
| Mint a scoped session: hosts, budget, per-call cap, expiry. |
| Every session, what it spent, and whether it is still live. |
| Kill a session. It stops paying on its next call. |
| Run as an MCP server over stdio. The default with no arguments. |
Claude Code
/plugin marketplace add aeronlabs/aeron-wallet
/plugin install aeron-wallet@aeronlabsCursor
Gemini CLI
gemini extensions install https://github.com/aeronlabs/aeron-walletVS Code
code --add-mcp '{"name":"aeron-wallet","command":"npx","args":["-y","aeron-wallet","mcp"]}'Anything else that speaks MCP
{
"mcpServers": {
"aeron-wallet": {
"command": "npx",
"args": ["-y", "aeron-wallet", "mcp"]
}
}
}Four tools: get_address, get_balance, pay, history. An unbound server
also gets create_session, list_sessions, and revoke_session.
A session is a scope you can hand to an agent without handing over the wallet. It names the hosts that may be paid, a total budget, a per-call cap, and an expiry:
aeron-wallet session create --host inference.aeron.sh --budget 0.25 --ttl 2hThat prints a token, once. Bind a server to it and every call through that server inherits the scope:
{
"mcpServers": {
"aeron-wallet": {
"command": "npx",
"args": ["-y", "aeron-wallet", "mcp"],
"env": { "AERON_WALLET_SESSION": "<token>" }
}
}
}A bound server deliberately has no session tools. An agent that could mint itself a wider session would not be contained by one. It also cannot reach a host outside the scope: the wallet refuses before the request goes out, so an agent talked into paying an attacker's endpoint never contacts it.
Revoking takes effect on the next call, including for a server already running, because the scope is re-read every time rather than captured at startup.
aeron-wallet pay --session <token> <url> applies a scope to a single call.
Sessions narrow the wallet; they never widen it. The caps below still apply underneath, so a $5 session on a $1/day wallet spends $1 a day.
The key is generated on your machine on first run and written to
~/.aeron/wallet/key with 0600 permissions. It never leaves the machine and
nobody else can derive your address. Every install creates a different wallet.
Two consequences worth planning for:
Ephemeral containers. If $HOME is wiped between runs, the wallet
regenerates and any USDG left on the old address is stranded. Mount a volume
for ~/.aeron, set AERON_WALLET_DIR to a path that persists, or supply the
key yourself with AERON_WALLET_KEY.
Hot wallet. The key sits unencrypted on disk so an agent can sign without a prompt. Keep the balance small. Fund it the way you would top up a prepaid card, not the way you would fund savings.
The wallet refuses to sign above either cap, so a loop cannot drain it.
Variable | Default | Meaning |
|
| Largest single payment. |
|
| Total for the current UTC day. |
Reading a 402 sounds like one line — take accepts[0] from the body — and that
line works against servers written the same way this wallet was. It works
against almost nothing else. On a survey of the machine-payable endpoints
listed on Robinhood Chain, not one merchant put this rail's offer first:
every one of them leads with Base, and the payable entry sits somewhere down a
list of a dozen.
So the offer is searched for, not assumed, across every shape merchants actually use:
What differs | What is done |
Offers in the JSON body, or in a base64 | Both are read, and the same offer stated twice is one offer |
The amount is | Either is accepted |
The list mixes chains and address formats this wallet has no key for | Non-EVM entries are skipped rather than treated as errors |
Several offers are payable | The cheapest one wins |
Nothing is payable | The refusal names what was offered, so the reason is actionable |
v1 carries the payment in X-PAYMENT and names the scheme and network at the
top level. v2 carries it in payment-signature, names neither, and states the
chosen offer verbatim in accepted — a rebuilt copy does not match, because
the server compares it against what it advertised. Answering a v2 merchant in
v1's form does not degrade; it is refused.
Worse, the split is not clean in the wild: merchants advertise a v2 header
beside a v1 body, and one host in a family of five wants X-PAYMENT while its
siblings want payment-signature. So the payment is offered in the form the
version asks for and, if that is refused outright, in the other one. Both
carry the same signed authorization, whose EIP-3009 nonce can be spent
exactly once — so the fallback cannot pay twice, however the server answers.
A request that comes back 4xx is not one situation, it is three, and they
differ in the only way that matters: whether the money left the wallet. The
signal is the settlement receipt — a service that settled returns
X-PAYMENT-RESPONSE with a transaction hash, and one that did not, does not.
| Charged | What happened |
| yes | The service answered. |
| no | HTTP 402. The service refused the payment; the authorization is unspent. |
| no | The service returned an error and declined to charge — usually its own upstream failed. |
The case worth naming: a settled row with a reason means the money
moved and nothing came back. That is the only outcome where the wallet is out
of pocket for nothing, so it is reported as itself rather than folded in with
refusals that cost nothing.
Only settled counts against DAILY_CAP_USD. A refusal and an upstream
failure leave the balance untouched, so neither eats into the cap.
reason quotes the service's own message when it gave one, instead of a
generic phrase — an agent operator reading a log needs to know whether to
retry, top up, or fix the seller.
Variable | Default |
|
|
|
|
|
|
|
|
| unset. Overrides the stored key. |
| unset. Binds the whole process to one session. |
Published from a tag by GitHub Actions using npm trusted publishing, so no
long-lived npm token exists to leak and every tarball carries a provenance
attestation: proof of the commit and workflow it was built from. Verify with
npm audit signatures after installing.
Payments settle on Robinhood Chain mainnet in USDG through the Aeron
facilitator at x402.aeron.sh. The wallet works with any x402 endpoint on the
same network, not only Aeron's.
More at aeron.sh/wallet.
Create a scoped session: allowed hosts, a total budget, a per-call cap, and an expiry. Returns a token that binds an agent to that scope.
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | Yes | lifetime, e.g. 90, 30m, 2h, 1d | |
| hosts | Yes | hostnames this session may pay, e.g. inference.aeron.sh | |
| budgetUsd | Yes | total USD this session may spend | |
| maxPerCallUsd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full behavioral burden, and it only reveals that a token is returned and binds an agent to a scope. It does not disclose side effects, whether the session persists until expiry or revocation, authorization requirements, or how budgets and caps are enforced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tightly written sentence with a colon-delimited list covers the tool's purpose and key parameters without redundancy. The key outcome, token return, is stated clearly at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return value and the parameter concepts, which is important because no output schema or annotations exist. However, it omits how the token is consumed, whether maxPerCallUsd is optional, and any behavioral caveats, so an agent must infer several operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description compresses all four parameters into named concepts: hosts, total budget, per-call cap, and expiry. It adds particular value for maxPerCallUsd, which has no schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Create a scoped session') and enumerates the exact constraints the session enforces, ending with the token return. This clearly separates it from sibling tools like list_sessions, revoke_session, pay, and get_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the create verb and by sibling names, but the description never states when to choose this session-creation path over alternatives or how the returned token is meant to be used with pay. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The wallet address on Robinhood Chain. Fund it with USDG to pay for services.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explicitly state that the tool is read-only, returns the address string, or has no side effects; it only describes what the address is and how funds should be used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences with no filler. It front-loads the core resource ('wallet address on Robinhood Chain') and adds one relevant funding detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter getter, the description provides a workable minimum: it names the chain and the funding purpose. However, with no output schema or annotations, it leaves unspecified what the return value looks like and whether any prerequisites or side effects exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because no additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as the wallet address on Robinhood Chain and explains its role in funding services, which distinguishes it from siblings like get_balance and pay. It relies on the tool name 'get' for the verb rather than explicitly stating 'returns the address', so it is clear but not fully self-contained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction to fund the address with USDG to pay for services implies when the tool is useful, but it does not explicitly say when to call get_address versus alternatives such as get_balance or pay. The usage context is implied rather than stated as clear guidance with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ETH and USDG balances of this wallet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It conveys a read-only balance lookup by implication, but it does not explicitly state the absence of side effects, authentication assumptions, or whether balances include pending transactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every element—asset types, 'balances', and wallet scope—adds useful meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter balance lookup, the description is nearly complete: it names the wallet scope and the returned asset types. It does not specify the response structure or define 'this wallet', but those gaps are minor given the absence of an output schema and parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is no parameter behavior for the description to document. The baseline of 4 applies because no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('ETH and USDG balances') and scopes it to 'this wallet', making the tool's purpose easy to infer. It does not explicitly state a verb or name sibling alternatives, but the asset-specific wording distinguishes it from session, address, and payment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use—checking the current wallet's ETH/USDG balance—is implied by the phrase 'balances of this wallet'. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent payments made by this wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It states the tool returns recent payments but does not disclose ordering, whether it includes both sent and received payments, read-only nature, or any limitations. The description is minimal and leaves key behavioral traits unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact phrase with no redundant words. It is appropriately short for a simple tool, though it could have included a verb without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter and no output schema, so the description should at least clarify what 'recent payments' means and how 'limit' behaves. It does not mention the parameter or any return details, leaving gaps for an agent trying to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description makes no mention of the 'limit' parameter. The schema documents the range and default, but the description adds no meaning about how the parameter affects results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('recent payments') and scope ('made by this wallet'), which distinguishes it from sibling tools like get_balance or pay. It lacks an explicit verb like 'list' or 'show', but the fragment is unambiguous enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_balance or pay. The description gives no context for selecting it among the siblings, leaving it to the agent to infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every session, with what it has spent and whether it is still live.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It does disclose that the tool returns session spend totals and liveness status, which implies a read-only listing. However, it does not explicitly state that there are no side effects, nor does it mention authentication, ordering, pagination, or session scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core output and key attributes. Every word earns its place and there is no redundant or unclear filler. It is an excellent model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description covers the basics: what is returned and two key attributes. But it leaves important context ambiguous, such as whose sessions are listed, what 'spent' means exactly, and how this relates to sibling tools. Without an output schema or annotations, these gaps make the description merely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is no parameter semantics for the description to add. The schema already fully covers the parameter surface with 100% coverage. A baseline of 4 is appropriate because nothing is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates that the tool returns every session along with spend amount and live status. Though it lacks an explicit verb, the tool name plus 'Every session' makes the enumeration operation unmistakable. It is clearly distinct from siblings like create_session, revoke_session, and get_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus sibling alternatives such as history or get_balance. It also does not clarify scope, such as whether sessions belong to the current user or all users, or what time range is covered. The agent is left to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call a machine-payable (x402) endpoint and pay in USDG if it answers 402. Budget caps apply.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| body | No | JSON body to send | |
| method | No | POST |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the core behavior—calling an endpoint and conditionally paying USDG—and mentions budget caps. However, it omits important behavioral context such as irreversibility, authentication requirements, failure handling, rate limits, or what happens if the endpoint returns a non-402 response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense, front-loaded sentence with no wasted words. It communicates the main action and constraint efficiently. However, it is terse enough that some operational clarity is sacrificed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a payment tool with no annotations and no output schema, the description is incomplete. It lacks return value information, failure modes, budget cap details, authentication requirements, and any indication of what response the caller should expect. An agent would be uncertain about the full consequences of invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (body is described in the schema), and the description adds no parameter-level meaning. The required 'url' parameter is not explained beyond being an endpoint, and 'method' has no semantic guidance. Since coverage is low, the description needed to compensate but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—'Call a machine-payable (x402) endpoint'—and the exact condition for payment: 'pay in USDG if it answers 402.' This clearly distinguishes it from sibling tools like get_balance, history, and create_session, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, when not to use it, or what prerequisites exist (e.g., sufficient balance, valid session). The only hint is 'Budget caps apply,' which is a constraint rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revoke a session by id. It stops paying on its next call.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must bear the burden of disclosing behavioral traits. It does reveal the meaningful consequence that the session stops paying on its next call, which is useful, but it does not clarify whether revocation is irreversible, idempotent, or restricted to active sessions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally short and front-loaded: the first sentence names the action and target, and the second adds a clarifying behavioral consequence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers the core action and one consequence, but with no output schema and no annotations, it leaves open important details such as return values, error conditions, and idempotency. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only the parameter name id plus its type in the schema, the description adds almost no semantic value beyond saying "by id." It fails to explain what kind of id this is (e.g., session id from list_sessions) or how the id is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (revoke), the target (a session), and the mechanism (by id). It also communicates the key semantic distinction from sibling tools like pay and create_session by noting the session stops paying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as list_sessions or create_session. The description implies a use case but does not state prerequisites, exclusions, or scenarios where another tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0create_sessionget_addressget_balancehistorylist_sessionspayrevoke_sessionScored across 7 tools
Each tool targets a distinct concern: wallet address, balances, payment execution, payment history, and session lifecycle. There is no meaningful overlap between payment history and session listing because one is about transactions and the other about scoped spending sessions.
Most tools follow a clear verb_noun pattern: get_address, get_balance, create_session, list_sessions, revoke_session. The single exception is 'history', which is a noun rather than a verb-led name like 'get_history' or 'list_payments'.
Seven tools is well-scoped for a wallet and session-management server. Each tool earns its place and the size is neither bloated nor overly thin.
The core wallet capabilities and session lifecycle are covered: address, balance, payment, history, create, list, and revoke. Minor gaps remain, such as no way to retrieve full session configuration details or individual payment records, but agents can work around this with the current surface.
Pay for HTTP APIs and charge for your own: x402 micropayments in USDC on Base.
Agent x402 Paywall MCP — Coinbase HTTP 402 protocol + on-chain settlement. Agents pay per-call
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
Wallet and payments for AI agents: auto-pay x402 APIs in USDC on XDC, within on-chain limits.
