nano-wallet
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NANO_NODE_URL | No | URL of the Nano node used for balance and receive operations. | |
| NANO_WALLET_ALLOW_SEND | No | Set to '1' to enable the send tool; otherwise send is disabled. | |
| NANO_WALLET_MAX_SEND_XNO | No | Maximum amount in XNO that can be sent per call (default 1.0 XNO). | |
| NANO_WALLET_REPRESENTATIVE | No | Override the representative account for new wallets. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_addressB | Generate a Nano (XNO) receiving address inside this process. Offline: no network call is made. The seed and private key are never returned, transmitted, logged or displayed. |
| validate_addressA | Checksum-verify a Nano (XNO) address. Returns valid=false with a machine-readable reason instead of throwing. A Nano address that fails its checksum looks entirely normal to the eye and can never receive a payment. |
| balanceB | Read an account's balance and what is waiting to be pocketed. The balance is the account's latest block; |
| receiveB | Pocket incoming XNO. Receiving is not spending: it moves nothing out of the account and passes through no spend gate. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a distinct action on a distinct concept: reading state (balance), generating a keypair (create_address), moving incoming funds (receive), and checking an address (validate_address). There is no plausible case where an agent would confuse one for another, and the descriptions reinforce the boundaries.
Two tools follow a clean verb_noun pattern (create_address, validate_address), but 'balance' is a bare noun and 'receive' is a bare verb, breaking the pattern. The names are still readable and unambiguous, so this is a mixed convention rather than a chaotic one.
Four tools is small but each covers a genuinely separate primitive of a wallet (read, keygen, deposit, validate), so nothing feels padded. It sits at the lean edge of the appropriate range, with the missing spend path being a coverage gap rather than a count problem.
The surface covers receiving-side lifecycle only: there is no send/transfer tool, no fee or spend-gate operation despite 'spend gate' being referenced in the receive description. Other gaps (listing created addresses, transaction history) leave an agent unable to complete the most basic outbound wallet workflow.