Nano MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NANO_SEND | No | `on` to allow sending | off |
| NANO_PAY_TO | No | The address invoices are paid to (no invoices without it) | |
| NANO_RPC_URL | No | The node for reads, checks and publishing; use your own node for real money | https://node.nano133.com/rpc |
| NANO_WORK_URL | No | Where proof of work comes from (work_generate) | NANO_RPC_URL |
| NANO_STATE_DIR | No | Invoices and the send journal (keep it; servers that share it take turns) | ~/.nano-mcp |
| NANO_WALLET_SEED | No | The seed itself, instead of the file (the file is safer: it stays out of config files and logs) | |
| NANO_REPRESENTATIVE | No | The representative a new wallet opens with (required before its first receive; a list); an open wallet keeps its own | |
| NANO_SEND_ALLOWLIST | No | The only addresses the wallet may pay; sending stays off without it, unless NANO_SEND_ANY_ADDRESS=1 | |
| NANO_WALLET_ADDRESS | No | The send wallet's address; the server refuses to send unless the seed gives exactly this address | |
| NANO_INVOICE_MINUTES | No | How long an invoice is open | 15 |
| NANO_SEND_ANY_ADDRESS | No | `1` lets the wallet pay any address, when no allowlist is set (only the value `1` counts) | |
| NANO_WALLET_SEED_FILE | No | A file that holds the seed (64 hex digits, or a 12/24-word phrase); it must be `chmod 600` | ~/.nano-mcp/seed |
| NANO_SEND_DAILY_CAP_XNO | No | The most all sends may move in 24 hours (≤ 10) | 0.05 |
| NANO_INVOICE_GRACE_MINUTES | No | How long after that a late payment still counts | 60 |
| NANO_SEND_MAX_PER_CALL_XNO | No | The most one send may move (≤ 1) | 0.01 |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| nano_balanceB | An account's confirmed balance and what waits for it to receive, in XNO and raw. |
| nano_account_infoB | An account's frontier (latest block), representative, block count, balance and when it opened. An account that never received anything is 'not opened'. |
| nano_historyA | An account's latest sends and receives, newest first. Use |
| nano_receivableB | Sends waiting for an account to receive them (largest first), with sender and amount. |
| nano_rateA | XNO in US dollars (the median of public price feeds). Give amount_usd or amount_xno to convert. |
| nano_create_invoiceB | An invoice for a price in USD or XNO, paid to the configured address (NANO_PAY_TO). It asks for an exact amount: the price plus a few raw that identify this invoice. Show the payer the exact amount and the nano: link. No key is needed. |
| nano_wait_for_paymentA | Waits (up to timeout_seconds, at most 120) until the invoice is paid, its payment is seen but not yet confirmed (pending), or it expires. Call it again to keep waiting. |
| nano_verify_paymentB | Either checks an invoice (invoice_id, optionally the payer's block hash), or checks any block: a confirmed send of exactly amount to |
| nano_walletB | The scoped send wallet: whether sending is on, its address (fund it here), balance, limits and what is left in the last 24 hours. Never the seed. |
| nano_sendA | Sends real XNO from the scoped wallet. It first receives what waits, then checks the per-send limit, the 24-hour cap and the allowlist, and sends once. Make a new idempotency_key for each payment and give the same one when you retry it: a retry then never pays twice. Confirm amount and address with the user before you send. |
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 10 tools
Most tools have distinct purposes (balance vs history vs receivable vs rate vs invoice lifecycle vs send). However nano_balance and nano_account_info overlap on balance reporting, and nano_receivable partly overlaps with the 'waiting to receive' portion of nano_balance, creating some potential confusion.
All tools share the consistent nano_ prefix, which aids grouping. The suffix style is mixed (noun-style like nano_balance, nano_history, nano_wallet vs verb_noun like nano_create_invoice, nano_verify_payment), but it remains readable and predictable.
Ten tools is well-scoped for a crypto/payment server, covering account queries, pricing, and the full invoice/payment flow without redundancy or bloat.
The surface covers account reading, pricing, invoice creation, payment waiting/verification, wallet management, and sending, which is close to full lifecycle coverage. A few operations like refunds or explicit receive control are absent, but nano_send auto-receives so core workflows are not blocked.