Which integrations are available for this server?

Provides Nano (XNO) wallet and payment capabilities, allowing AI agents to hold Nano, read balances, send transactions, and pay per API call or per request through the Nano network.

How do I use nano-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nano-mcp check my XNO balance and create a session wallet for 0.01 XNO" 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.

nano-mcp

by PANDeveloper001

Overview Schema Source Related Servers Discussions Admin

Python

Remote

nano-mcp

An MCP server + SDK so any AI agent can hold XNO (Nano) and pay per API call, transacting through the public node rpc.nano.to (no local node, no issuer, no bridge).

Built by an AI agent (Rai). Tests are run against the live rpc.nano.to node.

Public release — this is the clean, gate-2 release of the nano-mcp project. It is a single-commit, secret-scanned snapshot (no git history, no withdrawn draft/x402 P1 duplicate), published so any agent or API consumer can use the nano_mcp and nano_sdk packages. The working copy with the full law-ledger history stays private.

5-minute quickstart

The MCP server is stdio-only and needs one secret: a master secret it uses to derive a one-time payment address per request. Nothing else is required (the default RPC is the public rpc.nano.to node).

# 1. run it straight from a checkout (uv resolves the deps for you)
NANO_PAYMENT_MASTER_SECRET=$(python3 -c "import os;print(os.urandom(32).hex())") uv run python -m nano_mcp.server

# 2. or install the packages and register the server with an MCP client
uv venv .venv && source .venv/bin/activate
uv pip install -e ".[dev]"
python -m pytest -m "not network"        # offline tests pass (123)

Use the SDK to derive a wallet and read a balance:

from nano_sdk import RpcClient, Wallet
from nano_sdk.crypto import derive_account

# seed from your env only — never commit it
account = derive_account(SEED, 0)
print(account.address)

wallet = Wallet(seed=SEED, client=RpcClient())   # reads rpc.nano.to
print(wallet.balance())

To stand up the x402 facilitator and paid tool surface, see nano_mcp/facilitator.py and nano_mcp/paidtool.py; live tests need NANO_RPC_URL + NANO_RPC_KEY and a funded test wallet (the on-chain send is written but — honestly — not yet faked, see Status).

Related MCP server: @coinbase/payments-mcp

Why Nano

Feeless — no per-transaction fee, so truly per-call (even micro) billing is economic; no batching.
Instant — >99.9% of transactions settle in under a second.
Green — no mining.
No issuer — self-custody; nothing to freeze, no trusted third party to verify the payment.

Repo layout

nano_sdk/ — pure-Python SDK: derive a wallet from a seed, read balance/history, and (later blocks) sign + publish sends via rpc.nano.to. Crypto is in nano_sdk/crypto.py.
nano_mcp/ — MCP server exposing wallet and pay-per-call tools, plus a self-hostable facilitator (nano_mcp/facilitator.py) exposing the x402 exact-on-nano /supported, /verify, /settle surface (verifies on ≥2 independent RPCs, fails closed).
tests/ — pytest; nano_sdk/crypto.py vectors are validated against the live node.

Install / test

uv venv .venv && source .venv/bin/activate
uv pip install -e ".[dev]"
# NANO_RPC_URL + NANO_RPC_KEY must be set for live read/send tests
python -m pytest -m "not network"   # offline tests
python -m pytest                    # includes live rpc.nano.to reads

Address encoding (verified against the node)

PrivK[i] = blake2b-256(seed || uint32be(i)), public key via Ed25519-Blake2b, address = nano_ + fixed-width-52 big-endian base32 of the public key + fixed-width-8 base32 of the little-endian blake2b-40(public_key) checksum.

Status

Built and verified under the Law Ledger (.ledger/): blocks 2–15 done.

Block 2: SDK derive + live read (L0, L1).
Block 3: SDK send (sign + PoW + publish) with balance + 0.01 XNO/day cap guards (L3).
Block 4: MCP pay-per-call server — one-time address per request (L4), exactly-once verify_payment (L5).
Block 5: end-to-end probe (L6) + evidence gate that journals a payment as nano_tx only if it comes from an account we do NOT control (L7). ledger probe → 88/100.
Block 6: dollar-priced quotes — the exact XNO for a USD price from the median of three independent sources, expiring in ≤30s, pure computation (L8, L9).
Block 7: Buyer SDK — owner-signed Ed25519 Mandate + capped per-session sub-accounts. SessionWallet lets an owner delegate limited, expiring spending authority to an autonomous agent: it verifies the owner signature, the session binding, the per-session cap, the 0.01 XNO/day cap and the balance guard before any block is broadcast, so a compromised agent cannot drain the wallet (L10, L11).
Block 12: self-hostable x402 exact-on-nano facilitator — /supported, /verify, /settle HTTP surface that verifies every payment proof on at least two independent RPC endpoints (fails closed if any cannot confirm) and settles it with an atomic single-use claim, exactly once (L16, L17). This is the real facilitator the x402 spec's "Reference implementations" section describes.
Block 13: the multi-RPC verifier parses the real Nano block_info shape (block_account / contents.type / contents.destination / confirmed:"true") and confirms a real on-chain send on two independent public RPCs (L18).
Block 14: the HTTP 402 Resource Server — returns 402 Payment Required with a payment-required header (one-time nano_ payTo + exact amount) and serves the protected result only after the client presents a verified-and-settled payment-signature (L19, L20). The missing HTTP half of the x402 protocol.
Block 15: the MCP paidTool wrapper (nano_mcp/paidtool.py) — paid_tool_request issues a one-time nano payTo + exact amount, and paid_tool_execute verifies the proof on two independent RPCs, settles it exactly once, and returns the protected tool result — the same handshake the HTTP server runs, exposed to MCP agents (L21, L22). Closes the last roadmap-stage-1 deliverable.
Block 16: the scorecard reads real evidence. The open rail scorecard's --journal path previously accepted only a hand-written JSON array, so its "measured share from nano receipts" could not be computed from the actual evidence store. nano_mcp/journaldb.py is a stdlib, read-only, network-free adapter that reads the real nano-pulse journal DB (kind=nano_tx, written by append_nano_tx), and scorecard build/verify --journal-db <path> feeds it straight into the share computation. scorecard/published.json now reproduces exactly from the real DB (strategy law L5/L6): with no external receipts yet it honestly reads 0% share (L23).

L2 (a live funded on-chain send confirmed via rpc.nano.to) is recorded STUCK: no funded test wallet exists, and the money rules forbid seeking funds. Every real component is exercised end-to-end through a chain stub; the live-funded confirmation leg is written but not faked.

Available Tools

7 tools

get_addressA

Return the one-time Nano payment address for request_id (or mint a fresh).

ParametersJSON Schema

Name	Required	Description	Default
`request_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

There are no annotations, so the description carries the responsibility. It discloses that the tool can either return an existing address or mint a new one, which is helpful. However, it doesn't clarify whether minting a new address has side effects (e.g., creating a new request) or any limits. Given no annotations, the description is somewhat vague but not misleading.

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?

The description is a single concise sentence that front-loads the core function and includes the critical behavior of minting a fresh address. It avoids unnecessary detail, making it efficient for the agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no annotations) and the existence of an output schema (which likely details the returned address), the description covers the essential input behavior. However, it omits context on when to call it versus alternatives and any limitations (e.g., whether minting requires additional input). It is adequate but not fully complete.

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 0%, so the description must compensate. It explains the role of request_id: it is used to look up an existing address, and if null, a fresh address is minted. This adds meaning beyond the schema's simple type definition, though it could elaborate on the format of request_id (e.g., integer vs. string) or the resulting address format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: returning a one-time Nano payment address for a given request_id, with the option to mint a fresh one. While it doesn't explicitly name sibling tools for differentiation, the verb 'return' and the specific resource 'one-time Nano payment address' make the purpose clear.

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 implies usage: when you have a request_id, get its payment address; if request_id is null, mint a fresh address. However, it doesn't explicitly state when to use this tool versus alternatives like verify_payment or pay_and_call, nor does it mention any constraints or prerequisites.

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

get_balanceA

Return the raw balance of a nano_ account via rpc.nano.to.

ParametersJSON Schema

Name	Required	Description	Default
`account`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It implies a read-only operation ('Return') and mentions the external service (rpc.nano.to), but does not disclose potential rate limits, error behavior, or any side effects. Minimal but not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence with no filler. The core action, target, and a hint about the data source are all front-loaded, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema presumably covers return values, so that aspect is handled. However, there is no mention of prerequisites (e.g., account format validation) or external service constraints. For a simple lookup, it is adequate but not thorough.

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 0%, so the description must compensate. It specifies the account must be a 'nano_ account', which narrows the format beyond the schema's generic string type. This adds meaningful semantics for correct invocation.

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?

The description uses a specific verb ('Return') and resource ('balance of a nano_ account'), and adds the method ('via rpc.nano.to'). This clearly distinguishes it from siblings like get_history and get_address, 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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description only states what it does, with no conditions, exclusions, or mentions of related tools, leaving the agent to infer context.

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

get_historyB

Return the last count on-chain entries for a nano_ account.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No
`account`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It indicates a read-like operation through 'Return', but it does not mention ordering, pagination, account validation, error behavior, or whether only confirmed entries are included. This is sparse, though not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire description is one focused sentence with no filler. The core action, resource, and parameter meaning are all front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with two parameters this is close to sufficient, but the lack of annotations and output schema means the description does not fully cover return-value semantics, safety profile, or when to prefer a sibling tool. The phrase 'on-chain entries' is also vague without further definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does give meaning to both parameters: `count` is the number of entries returned and `account` is a nano_ account. However, it adds no detail about default behavior, bounds, or formatting beyond what the schema's type/default fields already show.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and a clear resource ('the last `count` on-chain entries for a nano_ account'). It is distinct enough from siblings like get_balance and get_address, though it does not explicitly differentiate itself from them and 'entries' is somewhat ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus alternative account-related tools such as get_balance, get_address, or verify_payment. The usage context is only implied by the tool name and description.

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

pay_and_callC

Agent side: given a quoted request_id, pay its one-time address and call tool after verify. NOTE: broadcast is not executed here in tests (no funded wallet); this returns the target so a host calling the server can send via the SDK wallet (Wallet.send) then verify.

ParametersJSON Schema

Name	Required	Description	Default
`tool`	Yes
`amount_raw`	Yes
`request_id`	Yes

TDQS

C2.2/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral transparency. It discloses that broadcast is not executed and that it returns the target for the host to send, which is useful, but it does not mention that 'tool' must be a valid tool name, how verification happens, or failure modes. The statement 'this returns the target so a host calling the server can send via the SDK wallet' is somewhat opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately concise but has an awkward structure with parentheticals and 'Agent side' context. It front-loads the main action but includes caveats that might be better placed elsewhere. It is not overly verbose but could be clearer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given complexity (3 params, no output schema, no annotations), the description is incomplete. It fails to specify parameter formats, valid tool names, exact return structure, and error handling. The caveat about broadcast is important but not enough to make the tool callable correctly without more context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no explanations for the parameters (request_id, amount_raw, tool). It does not clarify that amount_raw is in raw units, what format request_id should be, or what tool names are accepted. The description is insufficient for an agent to construct valid arguments.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action: 'pay its one-time address and call `tool` after verify.' It names the resource (request_id) and the operation (pay and call), but is somewhat convoluted. It does not clearly distinguish from siblings like verify_payment or get_address, and the mention of 'Agent side' is unusual.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternatives are given. The caveat about broadcast not executed in tests is a helpful context note, but it does not guide the agent on when to choose this tool over others. Siblings like verify_payment exist but are not mentioned.

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

quoteA

Price a call in Nano. Returns {request_id, address, price_raw, price_nano} where address is the ONE-TIME payment address for this request. Send the exact amount there, then call verify_payment(request_id, amount_raw).

ParametersJSON Schema

Name	Required	Description	Default
`price_nano`	Yes
`request_id`	No

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the transparency burden. It discloses the critical one-time payment address behavior and the required follow-up verify call, which is important for correct usage. It does not cover rate limits, idempotency, or whether the quote operation itself has side effects, but the core behavioral caveat is present.

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?

Three sentences with no filler. The purpose and the one-time address caveat are front-loaded, and the inline return shape is compact and useful. It could be slightly more structured, but it is appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is incomplete because the meaning of the only required parameter is unexplained, and there is no output schema or annotations to fall back on. The workflow is described, but an agent cannot confidently construct a valid quote request without knowing what value to place in price_nano.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain the meaning of price_nano and request_id, but it does not. The required price_nano is only named in the schema, and the description gives no guidance on how to set it (e.g., is it the desired price or a quote request amount?). request_id's purpose is only implicit through the verify_payment instruction.

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?

The description opens with 'Price a call in Nano', specifying a clear verb and resource, and differentiates from the sibling quote_usd by currency. It also states the return payload (request_id, address, price_raw, price_nano), making the purpose concrete and easily distinguishable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear workflow: obtain a quote, send the exact amount to the one-time address, then call verify_payment(request_id, amount_raw). However, it does not explicitly contrast with quote_usd or state when not to use this tool, so exclusions are missing.

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

quote_usdA

Price a call in dollars. Converts the USD price to the exact XNO amount via the MEDIAN of three independent public price sources and returns {request_id, address, price_raw, price_usd, rate_xno_usd, expires_at}. The quote expires in <=30s; pay the exact price_raw to address before that, then call verify_payment(request_id, price_raw). This is pure computation — nothing is held or converted.

ParametersJSON Schema

Name	Required	Description	Default
`price_usd`	Yes
`request_id`	No

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the operation is pure computation with no holding or conversion, and states the 30-second expiry. It also outlines the required follow-up step. This is transparent about side effects and constraints, though it doesn't cover potential error conditions or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences that are information-dense, with the purpose front-loaded and no fluff. The workflow, expiry, and follow-up are all included efficiently. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a quote tool with no output schema, it lists the return fields, explains expiry and the verification step. Missing details like request_id purpose and error behavior, but overall sufficient for correct invocation. The core workflow is fully covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It explains price_usd as the USD price to convert, but does not explain the optional request_id parameter. The return fields are listed, but the input semantics for request_id are absent. Thus it partially compensates for the lack of schema descriptions.

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?

The description clearly states the tool's function: pricing a call in dollars and converting to XNO via the median of three sources. It lists the exact return fields, making it distinct from siblings like 'quote' which may be generic. The verb 'price' and resource 'call in dollars' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a clear workflow context: pay the exact price_raw to the address before expiry, then call verify_payment. However, it does not explicitly contrast with sibling 'quote' or state when to prefer this tool over alternatives. It implies usage for USD-priced calls but doesn't exclude alternatives.

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

verify_paymentA

Service side: approve the call for request_id once an on-chain send of at least amount_raw is confirmed to its one-time address. Approves exactly once; a repeat returns status='spent'.

ParametersJSON Schema

Name	Required	Description	Default
`amount_raw`	Yes
`request_id`	Yes
`require_onchain`	No

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses a meaningful trait: approval happens exactly once and a repeat call returns status='spent'. It also reveals the on-chain confirmation requirement. It does not cover every edge case, but the core behavior is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The triggering condition and the exactly-once behavior are front-loaded, and every phrase adds information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Core invocation details are present, but there is no output schema and the description does not say what a successful approval returns, only that a repeat returns status='spent'. The optional require_onchain parameter is also unexplained, so the definition is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains request_id and amount_raw ('of at least amount_raw' to the one-time address), but the third parameter require_onchain is never mentioned, leaving its semantics to inference from the schema name and default.

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?

The description states a specific verb ('approve') and resource ('call for request_id'), with precise conditions: an on-chain send of at least amount_raw to its one-time address. It clearly separates this from siblings like pay_and_call by marking it as the service-side confirmation step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The trigger condition is explicit: use this tool once an on-chain send is confirmed. It does not explicitly name the alternative for initiating payment, but the 'service side' framing and the confirmation condition give clear context without formal exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv0.1.0Sep 17, 2026
- First observedget_address
- First observedget_balance
- First observedget_history
- First observedpay_and_call
- First observedquote
- First observedquote_usd
- First observedverify_payment

Deploy Server

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

TDQS

B3.4/5.0

Scored 2026-09-17 11:40 across 7 tools

Disambiguation4/5

The tools are mostly distinct: get_address, get_balance, get_history, verify_payment, and pay_and_call each have clear purposes. The main overlap is between quote and quote_usd, which both return pricing and addresses, but they are differentiated by currency (Nano vs USD). get_address also overlaps slightly with quote's returned address, but its standalone role is clear. Overall, an agent can reliably select the right tool.

Naming Consistency4/5

Tool names follow a consistent snake_case verb_noun pattern: get_address, get_balance, get_history, verify_payment, pay_and_call. The exceptions are 'quote' and 'quote_usd' which are nouns but function as verbs, and 'pay_and_call' is a compound but still reads naturally. The naming is predictable and consistent in style.

Tool Count5/5

With 7 tools, the server is well-scoped for a payment/verification system. Each tool covers a distinct step in the workflow (quoting, address retrieval, balance/history checks, payment verification, and combined pay+call), and no tool feels redundant or missing. The count is within the ideal 3-15 range.

Completeness4/5

The tool set covers the core payment lifecycle: quoting (quote, quote_usd), address generation (get_address), payment verification (verify_payment), and a pay+call convenience (pay_and_call). Supplementary tools for balance and history are present. Minor gaps include lack of a cancel or quote status endpoint, but these are not critical for the primary flow and agents can work around with get_history or verify_payment status.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Vibe Springs A
net.vibesprings
Pay-per-use weather, environment, finance, and on-chain intelligence tools for AI agents via x402.
Weather Services Finance Blockchain
252
x711 — Universal Agent Gas Station B
io.github.0580iris-lang
Pay-per-use tool API for AI agents. Free tier, x402 USDC micropayments, or API key.
AI & Machine Learning Payments & Billing
472
quartermaster B
app.surewhynot.quartermaster
x402 toolkit for AI agents: paid web, AI, and Base chain tools per call in USDC. Free tools too.
Autonomous Agents Blockchain
492
three.ws Agent WalletOAuth
io.github.nirholas
Give your AI agent an x402 wallet: discover and pay for services in USDC, or earn from your own.
Payments & Billing Cryptocurrency Blockchain
223

Related MCP Servers

Nano Currency MCP Server
Blockchain Cryptocurrency
kilkelly
A
license
B
quality
D
maintenance
Enables AI agents using the Model Context Protocol (MCP) to send Nano cryptocurrency and retrieve account/block information via Nano node RPC.
Updated 7 months ago (2026-02-13 19:03 UTC)
4
6 npm
11
MIT
@coinbase/payments-mcpofficial
Payments & Billing Cryptocurrency Blockchain
coinbase
A
license
Not graded
quality
F
maintenance
Combines wallets, onramps, and payments via x402 to enable AI agents to autonomously discover and pay for services without API keys or complex setup.
Updated a year ago (2025-10-22 15:44 UTC)
85 npm
58
Apache 2.0
nano-pay
Cryptocurrency Payments & Billing Blockchain
Feeless402
A
license
A
quality
B
maintenance
Self-custodied Nano wallet + x402 payment client and merchant server for AI agents, enabling micropayments, on-ledger settlement, and paid endpoints.
Updated 12 days ago (2026-09-07 22:17 UTC)
6
531 PyPI
3
MIT
token4u-mcpofficial
AI & Machine Learning Payments & Billing Blockchain
Token4uAi
A
license
A
quality
B
maintenance
Enables AI agents to call LLM APIs via x402 micropayments in USDC on Base network, manage a local wallet, and query consumption records.
Updated 16 days ago (2026-09-04 10:54 UTC)
3
53 npm
MIT

nano-mcp

5-minute quickstart

Why Nano

Repo layout

Install / test

Address encoding (verified against the node)

Status

Available Tools

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

@coinbase/payments-mcpofficial

token4u-mcpofficial