What can you do with this server?

This MCP server lets an AI agent interact with a local Kura wallet: read wallet/account state, check balances, review transaction history, look up ERC-8004 agent records on-chain, request user-approved payments, and fetch x402 paywalled resources. * get_wallet_status — Read wallet state, active account address, account list, and active account index (read-only). * get_balances — Read the active account's USDC and gas-token balances on the active network; gas field is omitted on Arc since USDC covers gas. * get_history — Read recent transaction attempts with statuses like sent, blocked, failed, signed, settled, or settle_failed. * lookup_agent — Read an ERC-8004 agent's on-chain registration and optionally compare a pay-to address or resource domain against the registered wallet/domain (read-only). * request_payment — Ask the user to approve a payment to an address; supports USDC or ETH, memo, optional agent_id check, and enforces limits/locks via the wallet app. * x402_fetch — Fetch a URL; if the server returns 402, request user approval for the required USDC payment, sign with EIP-3009, and re-fetch with the payment header to return the content.

de en es ja ko ru zh

Kura

by dinggi5

Overview Schema Source Related Servers Discussions Admin

Rust

Local

Kura (蔵 — a storehouse that guards your treasures)

A local EVM wallet for AI agents. On a Mac, when an AI like Claude makes an internet payment (x402), this is the wallet where a human approves it with a password.

Not a human wallet (like MetaMask) — it's for AI agents
Not a cloud SaaS — it runs locally only. Keys never leave this computer.
AI requests a payment → a human approves with a password → it executes
The chain is Base (Ethereum L2, near-zero fees). Default is the testnet (Base Sepolia)

At a glance

[ AI 앱 (Claude Code / 데스크톱) ]
        │  MCP로 "결제해줘" 요청
        ▼
[ Kura 데스크톱 앱 ]  ← 승인 팝업 → 사람이 비밀번호 입력
        │  서명 (키는 이 앱 안에서만)
        ▼
[ Base 체인 / x402 페이실리테이터 ]  ← 실제 결제

The password is only ever entered in the Kura app's input field. It never goes into chat windows, MCP, or config files.

Related MCP server: cardzero-mcp

Installation

Apple Silicon Mac (macOS 11 or later)

(A) Homebrew

brew install --cask dinggi5/tap/kura

(B) Download the DMG directly

Download Kura_<version>_aarch64.dmg from Releases, open it, and drag Kura into the Applications folder.

Since this is an app you're entrusting with your keys, I've written down the exact commands for verifying that the app you received is really the one I built in SECURITY.md.

(C) Build from source

Prerequisites: Rust, Node.js (20.19+ or 22.12+ — required by Vite 7), macOS.

git clone https://github.com/dinggi5/kura.git
cd kura
git checkout v0.1.1   # 배포본과 같은 소스. 빼면 개발 중인 최신 코드가 받아져요
npm ci                # package-lock.json 그대로 설치 (install 은 버전이 올라갈 수 있어요)

# 개발 모드로 바로 실행
npm run tauri dev

# 앱으로 빌드해 /Applications에 설치
npm run tauri build -- --bundles app --no-sign
ditto src-tauri/target/release/bundle/macos/Kura.app /Applications/Kura.app
open /Applications/Kura.app

Updates

The app updates itself.
Go to Settings → About to check the version and changelog, then click Install now and restart.

Only the check is automatic — installation always requires you to click it.
Downloaded files are installed only after their signature is verified (signature verification cannot be disabled). Details are in the "Updates" section of SECURITY.md.
If you don't want the automatic update-check traffic, turn off Settings → About → Check on startup.

Uninstalling

⚠️ Uninstalling the app does not delete your wallet. Keys, settings, and transaction history live in ~/.jigap outside the app, so removing just the app leaves them intact — I did this on purpose so you don't accidentally lose your assets (even brew uninstall --zap won't remove them).

# 앱만 제거 (지갑은 남음 — 나중에 다시 설치하면 그대로 이어서 써요)
brew uninstall --cask dinggi5/tap/kura   # 또는 /Applications/Kura.app 을 휴지통으로

To completely erase the wallet too on this Mac, follow this order:

First make sure you have the 12-word recovery phrase in hand. You can view it again via the key button in the app's header.
If there's a balance left, move it to another wallet.
Quit Kura completely (right-click the menu bar icon → Quit). If it's running, it writes a state file to ~/.jigap every few seconds, so a deleted folder will reappear right away.
Also quit any AI tools (like Claude Code) that have the Kura MCP attached.
If you had auto-start enabled, turn it off or run rm ~/Library/LaunchAgents/Kura.plist (this file remains if you delete the app via Trash. If you uninstall with brew uninstall --cask, it goes away with it).
Then run rm -rf ~/.jigap

Running that final rm -rf ~/.jigap without the 12 words means no one can ever recover that wallet's assets.

First run

Kura lives in the menu bar. When you launch it, a storehouse icon (◻︎) appears in the menu bar at the top of your screen, and the window only drops down when you click that icon. Clicking elsewhere closes it, and the app stays in the background waiting for AI payment requests. To quit completely, right-click the icon → Quit. (On first launch when no wallet exists yet, the window opens by itself.)

Create a wallet — set a password (8+ characters) that you'll enter for every transfer. Your key is encrypted and stored with this password (~/.jigap/wallet.enc).
Back up the seed — 12 words are shown. This is the real proof of ownership of your assets, so write them down on paper or in a password manager. Even if you forget your password, the 12 words alone can recover it: quit the app, first make sure you have the 12 words in hand, then delete ~/.jigap/wallet.enc and relaunch the app — you can restore it via Import on the first screen (you can also put them into any other standard BIP-39 wallet). However, deleting this file without the 12 words means losing your assets forever.
Welcome tour — walks you through funding, AI connection, and safety features. You can revisit it anytime from the ⓘ Help in the header.

Funding (USDC)

To make payments, your wallet needs USDC (digital dollars).

Tap Receive in the app to see your address and QR code.
When sending from an exchange or another wallet, be sure to select the Base network. Sending on another network will lose your funds.
On the testnet (default), it's not real money. Use the Faucet button on the receive screen to get free test coins and practice.
ETH is optional — for x402 payments, the facilitator pays the fee, so you can have 0 ETH. You only need a little ETH for gas when sending directly via the app's Send (Base fees are around a cent). Funding with USDC alone is enough.

Connecting AI (Claude)

Register the Kura server in your AI app's MCP settings to connect. Once connected, a "Claude connected" badge appears on the main screen. Since 0.1.2, the MCP server is built into the app, so you can connect without cloning the source or installing Rust.

The easiest way — the "AI Connect" screen in the app

Click the "AI not connected" badge at the top of the main screen to open the connection screen.

Claude Desktop — click the "Connect" button and an extension install window appears in Claude. Just click 'Install' and you're done.
Claude Code — registered with one click (the app runs claude mcp add for you). From the next claude launch, it's connected from any folder.

Below is how to do the same thing by hand.

Claude Desktop — one extension file is all you need

Download kura-<version>.mcpb from the releases page and double-click it — Claude Desktop will ask to install it. (Or go to Claude Settings → Extensions → Choose file.)

The extension contains no executable — it only has a launcher that verifies the signature of the signed and notarized MCP server inside the installed Kura.app and then runs it. So you need to install the Kura app first.

Claude Code · other MCP apps

claude mcp add --scope user kura -- /Applications/Kura.app/Contents/MacOS/kura-mcp

(--scope user is the option that makes it available everywhere, not just "this folder". If you only want it in one project, you can omit it.)

For other MCP apps, write it in the settings like this:

{
  "mcpServers": {
    "kura": {
      "command": "/Applications/Kura.app/Contents/MacOS/kura-mcp"
    }
  }
}

If you're developing from source

The repo root already has .mcp.json. Running claude in this folder picks it up automatically (the first time it asks whether to use the server — approve it). This path is for development, rebuilding with cargo run every time — if you're using an installed build, registering the app path above is the right approach.

Tools the AI can use: get_wallet_status · get_balances · get_history (read-only) · request_payment (payment request → approval popup in the app) · x402_fetch (calls a URL that requires 402 payment).

If you change the MCP tools, restart the AI app for it to take effect (the server is loaded once at session start).

How a payment flows

The AI requests a payment.
The Kura window appears showing how much, to where (it pops up automatically even if the window was hidden).
Enter the password and approve.
The payment executes and the result goes back to the AI. If you don't approve within 5 minutes, it's automatically rejected.

Security model

Password approval — by default, every payment requires password approval (if autonomous payments are enabled, exceptions apply only under the conditions below). Keys are stored encrypted (Argon2id + AES-256-GCM) and are only decrypted at payment time, then wiped immediately (if an autonomous payment session is enabled, they're kept in memory only while unlocked).
Limits — set how much can be sent per transaction / per day in settings (default: 5 USDC single, 20 USDC daily). Anything over is blocked.
Emergency lock — turning on the shield button in the header immediately blocks all transfers.
Trusted addresses · autonomous payments — for automatic approval without a password, session unlock + small limits + trusted address must all be satisfied. Otherwise, a password is always required.
Transaction history — records all outgoing transfers, blocked attempts, and signatures.
Local-first — keys (~/.jigap/) live outside the repo and never get committed to git.
No analytics, no font CDN — the app connects to the internet on its own for only three things: ①the RPC server used for balance lookups and transfers ②x402 addresses requested by the AI ③update checks (GitHub). Usage data is never sent anywhere, and fonts are bundled in the app, so the UI renders fine offline too.
Update checks can be disabled — on launch it asks GitHub whether a new version exists (your IP and current version are logged there). Turning off Settings → About → Check on startup removes even this traffic. Whether the check is on or off, installation only proceeds when you click it — nothing ever changes silently.

For developers

You can also drive the same wallet from the CLI kura (it shares the MCP server and core logic). It's already inside the installed app, so one line on your PATH and you're set:

sudo mkdir -p /usr/local/bin
sudo ln -sf /Applications/Kura.app/Contents/MacOS/kura-cli /usr/local/bin/kura
kura status

To run from source:

cargo run --manifest-path ./kura-mcp/Cargo.toml --bin kura -- status
cargo run --manifest-path ./kura-mcp/Cargo.toml --bin kura -- balance
cargo run --manifest-path ./kura-mcp/Cargo.toml --bin kura -- history --limit 10
cargo run --manifest-path ./kura-mcp/Cargo.toml --bin kura -- pay <주소> <금액> --token usdc
cargo run --manifest-path ./kura-mcp/Cargo.toml --bin kura -- fetch <URL>

pay/fetch never take a password via the CLI — the Kura app must be running, and a human enters the password in the approval popup.

Tests:

(cd src-tauri && cargo test)        # 백엔드(지갑·암호화·한도·송금)
(cd kura-mcp && cargo test)         # MCP/CLI 어댑터
npx tsc --noEmit && npx vite build  # 프론트

The procedure for producing a release build (signed, notarized DMG) is in docs/RELEASE.md. It needs an Apple Developer account and a one-time setup, and after that it's one line:

./scripts/release.sh

Tech stack


Desktop	Tauri (Rust + web frontend)
Frontend	React + Tailwind CSS, Framer Motion, Lucide, Pretendard
Chain	Base / alloy-rs
Payments	x402 (EIP-3009 off-chain signatures)
AI connect	MCP server (rmcp)

Structure: [Rust core (src-tauri)] ← MCP / CLI adapters (kura-mcp). Only the GUI process has key access (signing) — that's the last line of defense.

License · status

MIT license — since this is code that handles keys and money, I believe it should be something you can read, verify, and modify yourself.

If you find a vulnerability, please report it through the private channel in SECURITY.md before filing an issue. The same document also lists what Kura cannot protect against.

The bundled Pretendard font is under the SIL Open Font License 1.1 (full text).

The number one user is myself — a wallet for Korean developers and creators on Apple Silicon Macs who pay with local LLMs/Claude. It's still an early 0.1.x version, so I recommend learning on the default testnet first and only putting what you can afford to lose on mainnet.

Available Tools

6 tools

get_balancesA

Reads the active account's USDC (for payments) and gas-token balances on the active network (Base mainnet, Arc mainnet, Base Sepolia, or Arc testnet, per the user's setting). The eth field is the gas balance and is ABSENT on chains where gas is paid in USDC itself (Arc) — there the USDC balance already covers gas, so never add the two together. Errors if there is no wallet.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so admirably. It discloses that the `eth` field is absent on Arc, warns never to add USDC and eth balances together, and states the error condition if no wallet exists—critical behavior beyond a generic 'reads balances' line.

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: the first states the main purpose, the second explains the crucial Arc nuance, and the third covers failure mode. No filler, and the most important information is front-loaded.

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

Completeness5/5

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

For a zero-parameter read tool with no output schema, this is nearly complete. It explains the returned values (USDC and gas balances), names the `eth` field, clarifies the Arc exception, and states the error condition—enough for correct invocation and interpretation.

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?

The input schema has zero parameters, so schema coverage is trivially 100%. The description correctly provides no parameter-level detail since none is needed; the baseline of 4 applies.

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?

Description opens with 'Reads ... USDC ... and gas-token balances', a specific verb and resource, and immediately scopes to active account and network. It clearly differentiates itself from sibling tools like get_wallet_status or get_history by focusing on balance data, with concrete field semantics.

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 does not explicitly name alternatives, but it gives clear operational context: which networks apply, the Arc-specific gas behavior, and the no-wallet error condition. This makes the intended use obvious, although no exclusions or 'use X instead' guidance is stated.

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

get_historyA

Returns the active account's recent transaction attempts, newest first. status is one of sent, blocked, failed, signed (x402 signed, awaiting settlement), settled (x402 settled, settle_tx is the settlement tx), or settle_failed. Use limit to cap how many come back (default 20).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many recent entries to return (default 20, max 200).

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, and it discloses ordering, status value meanings, x402 settlement semantics, and the limit default. It does not mention authentication or response shape, but for a read-only history lookup this is solidly 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?

The description is compact and front-loaded with the core behavior. The status enumeration is detailed but earns its place because there is no output schema to convey that information.

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 simple one-parameter tool, the description covers ordering, statuses, and limit behavior. A fully explicit response structure would improve completeness, but nothing essential to deciding to call it or interpreting statuses is missing.

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?

The input schema already fully documents the single `limit` parameter, including default and max. The description only restates that limit caps results, adding no meaningful semantic value beyond the schema.

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 returns the active account's recent transaction attempts, newest first. This verb-resource pairing is specific and distinguishes it from sibling tools like get_balances and get_wallet_status.

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 intended use case is evident: call this when you need recent transaction attempts and their statuses. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to choose it appropriately.

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

get_wallet_statusA

Returns the wallet's state and address. state is encrypted (normal), legacy, or none. address is the ACTIVE account's address; accounts lists every account in the wallet (index, address, label) and account is the active index. Balances, history, and payment requests all use the active account, and only the user can switch accounts, in the wallet app. No password needed — read only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/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 disclosure. It states 'No password needed — read only', discloses state value semantics, and clarifies that account switching can only be done by the user. These are valuable non-obvious behaviors for an agent. It falls short of 5 only by not mentioning error cases or what happens when no wallet is present, but for this simple read the disclosure is quite adequate.

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 description is about 85 words and front-loads the core action then clarifies the fields. Every sentence contributes: the state vs. address, the accounts list, the active-account context, and the read-only note. There is no filler. One minor phrasing in 'state is encrypted (normal), legacy, or none' could be clearer, but it does not materially hurt readability.

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

Completeness5/5

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

With no output schema, this description is the complete contract for what the tool returns. It defines the 'state' enum, 'address', 'accounts' with index/address/label, and 'account' as active index. It also weaves in why this matters for sibling tools and that the user alone can switch accounts. For a parameter-less read-only status call, this is complete enough.

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?

This tool takes 0 parameters and the schema is complete (empty). With no parameters, the description does not need to add parameter meaning. The parameter_semantics baseline for 0 params is thus a 4, and the description has no unnecessary parameter-related bloat.

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 explicitly states the verb and resource: 'Returns the wallet's state and address.' It then enumerates exactly which fields are returned (state, address, accounts, account) and even gives possible state values. It differentiates itself from sibling tools by noting that balances, history, and payment requests all use the active account, making clear why this wallet-status read is distinct.

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 clear context: 'Balances, history, and payment requests all use the active account, and only the user can switch accounts, in the wallet app.' That tells an agent this tool supplies the account context needed before or alongside the sibling calls. It does not explicitly say 'call this before get_balances/get_history/request_payment', nor does it name the alternatives, so it stops short of a full when/when-not instruction.

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

lookup_agentA

Reads an agent's ERC-8004 record from the registry on the active Base network (read-only, on-chain only — the wallet never fetches the agent's website). Give it agent_id, the agent's number in the Identity Registry. Returns: registered, owner, wallet (the registered agentWallet), token_uri and the uri_domain read from it, declared_name (what the record calls itself), and feedback_clients (how many addresses left feedback). Pass pay_to and/or resource to also get a comparison: whether the address equals the registered wallet and whether the resource's domain equals the domain listed on-chain. IMPORTANT: registration is permissionless — anyone can register any name, domain, or wallet, and anyone can leave feedback. Being registered is NOT proof of safety. Only a mismatch is a strong signal, and only when the agent number came from a source you trust (the service's own docs), not from the payment response itself.

ParametersJSON Schema

Name	Required	Description
`pay_to`	No	Optional: an address to compare against the agent's registered wallet.
`agent_id`	Yes	The agent's ERC-8004 number (agentId — the Identity Registry NFT token id).
`resource`	No	Optional: a resource URL whose domain is compared with the domain listed on-chain.

TDQS

A4.7/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses read-only behavior, that the wallet never fetches the agent's website, the exact return fields, the effect of optional params, and the critical caveat that registration is permissionless and not proof of safety.

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?

Long but well-structured: purpose first, return fields, optional usage, then critical warning. Every sentence serves a purpose, including the trust caveat which is essential for correct interpretation. No filler.

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

Completeness5/5

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

With no output schema, the description provides a full return-field list and explains the trust implications of results. It covers network, parameters, and interpretation, making it complete for correct invocation and result understanding.

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 100%, so the baseline is 3. The description adds functional meaning for optional parameters by explaining that pay_to and resource trigger comparisons and what those comparisons determine, going beyond the schema's simple type 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?

States a specific verb ('Reads') and resource ('agent's ERC-8004 record from the registry on the active Base network'), and clarifies it is read-only and on-chain only. This distinguishes it from sibling tools like x402_fetch, which likely involve off-chain fetching.

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?

Provides clear context for when to use the tool (verifying an agent's on-chain record) and what optional parameters trigger comparisons. It does not explicitly name alternatives or exclusions, but the read-only, on-chain-only scope and safety caveats give sufficient guidance.

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

request_paymentA

Asks the user to make a payment. The wallet app opens an approval window, and the payment is only sent once the user approves it with their password (it waits up to 5 minutes). The one exception is autopay, which the user turns on themselves — only then can a payment be approved automatically, and only within an unlocked session, a small limit, and a trusted address. Arguments: to (recipient address), amount (decimal string), token (USDC by default, or ETH), memo (what the payment is for — the user reads it to decide, so always fill it in), and optionally agent_id (the recipient's ERC-8004 number, if a service told you one — the wallet then shows the user whether the address matches that agent's registered wallet). Per-payment and daily limits and the emergency lock are enforced by the app. Never send a password as an argument — the user types it in the app. Returns: status (approved/rejected/failed), tx_hash, and an explorer link.

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Recipient address (42 characters, starting with 0x).
`memo`	No	What the payment is for — the user reads this in the approval window, so fill it in.
`token`	No	Token: "USDC" (default) or "ETH".
`amount`	Yes	Amount as a decimal string, for example "1.5".
`agent_id`	No	Optional: the recipient's ERC-8004 agent number, if you know it from the service's own documentation or agent card. The wallet reads that agent's on-chain record and tells the user whether the address you are paying is the one registered for that agent. A mismatch is the useful part — a match is not proof of anything, since anyone can register. Leave it out if you don't know it; a wrong number just produces a "no such agent" note.

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does excellent work: it discloses the blocking wait, user password approval, autopay exception with preconditions, per-payment/daily limits, emergency lock, and the instruction never to send a password as an argument. It also reveals the response outcomes (status, tx_hash, explorer link). This level of transparency is well beyond what minimal descriptions provide.

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 description is long but every sentence earns its place; it front-loads the primary action and approval requirement, then covers exceptions, parameters, limits, and return values without redundancy. No fluff.

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

Completeness5/5

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

For a high-stakes payment tool with no annotations and no output schema, it is complete: it explains the full interaction flow, security constraints, parameter meanings, and return fields (status, tx_hash, explorer link). An agent has what it needs to call safely.

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 100%, so the baseline is 3, but the description adds meaningful semantics: memo must always be filled because the user reads it, token default behavior, and deep guidance on agent_id (mismatch is useful, wrong number yields no-such-agent, leave out if unknown). This goes beyond the schema.

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 asks the user to make a payment and describes the wallet approval flow. It does not explicitly differentiate from sibling x402_fetch, which might also involve payment, so the boundary is inferred rather than stated.

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?

Provides strong contextual guidance: this is the user-approval payment path, with a clear autopay exception and limits. It does not name alternatives or say when not to use it, but the context is unambiguous enough for an agent.

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

x402_fetchA

Fetches an x402 paid resource (a URL). It GETs the URL first; if the server answers 402 Payment Required, it asks the user to approve the required payment (exact scheme, the active Base network, USDC) in the wallet app, builds an EIP-3009 signature, and re-requests the same URL with an X-PAYMENT header to return the content. If no payment is required (no 402), it just returns the body. Approval works exactly as in request_payment (password by default; automatic only when the user has turned autopay on), and the app enforces per-payment and daily limits and the emergency lock. Never send a password as an argument. Arguments: url (required), memo (what the payment is for — the user reads it to decide). Returns: paid, status, http_status, body, and amount/pay_to/settlement when paid.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	URL of the paid resource to fetch (http/https).
`memo`	No	What the payment is for — the user reads this in the approval window, so fill it in.
`agent_id`	No	Optional: the seller's ERC-8004 agent number, if you know it from the service's own documentation or agent card. The wallet then reads that agent's on-chain record and shows the user whether the payment address and the resource domain match what is registered. Leave it out if you don't know it — a wrong number just produces a "no such agent" note.

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses the GET-first behavior, EIP-3009 signature, X-PAYMENT header, user approval flow, autopay behavior, per-payment and daily limits, emergency lock, and warns 'Never send a password as an argument.'

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 description is dense but well-organized: purpose first, then flow, approval behavior, safety constraints, argument list, and return fields. Every sentence contributes necessary operational detail with no filler.

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

Completeness5/5

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

Given the absence of annotations and output schema, the description is unusually complete: it explains the multi-step request flow, payment approval requirements, safety limits, arguments, and exact return fields. It covers what an agent needs to call the tool and interpret its result.

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 100%, so the baseline is 3. The prose recap of url and memo mostly mirrors the schema, and agent_id is not mentioned in the description, so it adds little semantic value beyond the input schema.

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 a specific verb and resource: 'Fetches an x402 paid resource (a URL).' It then details the 402-triggered payment flow, making it clear that this tool fetches content while handling required payments, distinct from siblings like request_payment.

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 gives clear context for use: GET the URL, handle 402 with payment approval, otherwise return the body. It references request_payment for approval semantics but does not explicitly state when to choose this tool over request_payment or lookup_agent.

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.

4 tool updatesv0.4.1Sep 17, 2026
- Changedget_history2 fields changed
  - removedInput schema / properties / limit / default
```
Removed value: -null
```
  - removedInput schema / properties / limit / nullable
```
Removed value: -true
```
- Changedlookup_agent4 fields changed
  - removedInput schema / properties / pay_to / default
```
Removed value: -null
```
  - removedInput schema / properties / pay_to / nullable
```
Removed value: -true
```
  - removedInput schema / properties / resource / default
```
Removed value: -null
```
  - removedInput schema / properties / resource / nullable
```
Removed value: -true
```
- Changedrequest_payment6 fields changed
  - removedInput schema / properties / agent_id / default
```
Removed value: -null
```
  - removedInput schema / properties / agent_id / nullable
```
Removed value: -true
```
  - removedInput schema / properties / memo / default
```
Removed value: -null
```
  - removedInput schema / properties / memo / nullable
```
Removed value: -true
```
  - removedInput schema / properties / token / default
```
Removed value: -null
```
  - removedInput schema / properties / token / nullable
```
Removed value: -true
```
- Changedx402_fetch4 fields changed
  - removedInput schema / properties / agent_id / default
```
Removed value: -null
```
  - removedInput schema / properties / agent_id / nullable
```
Removed value: -true
```
  - removedInput schema / properties / memo / default
```
Removed value: -null
```
  - removedInput schema / properties / memo / nullable
```
Removed value: -true
```

1 tool updatev0.4.0Sep 9, 2026

Changedrequest_payment1 field changed

addedInput schema / properties / agent_id

Added value: +{
+  "default": null,
+  "description": "Optional: the recipient's ERC-8004 agent number, if you know it from the service's own\ndocumentation or agent card. The wallet reads that agent's on-chain record and tells the\nuser whether the address you are paying is the one registered for that agent. A mismatch\nis the useful part — a match is not proof of anything, since anyone can register.\nLeave it out if you don't know it; a wrong number just produces a \"no such agent\" note.",
+  "format": "uint64",
+  "minimum": 0,
+  "nullable": true,
+  "type": "integer"
+}

2 tool updatesv0.3.0Aug 29, 2026

Addedlookup_agent

Changedx402_fetch1 field changed

addedInput schema / properties / agent_id

Added value: +{
+  "default": null,
+  "description": "Optional: the seller's ERC-8004 agent number, if you know it from the service's own\ndocumentation or agent card. The wallet then reads that agent's on-chain record and shows\nthe user whether the payment address and the resource domain match what is registered.\nLeave it out if you don't know it — a wrong number just produces a \"no such agent\" note.",
+  "format": "uint64",
+  "minimum": 0,
+  "nullable": true,
+  "type": "integer"
+}

5 tool updatesv0.2.0Aug 23, 2026
- First observedget_balances
- First observedget_history
- First observedget_wallet_status
- First observedrequest_payment
- First observedx402_fetch

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

A4.4/5.0

Scored 2026-09-17 06:20 across 6 tools

Disambiguation5/5

Each tool targets a clearly distinct concern: balances, wallet state, history, agent registry lookup, generic payments, and paid URL fetching. Although request_payment and x402_fetch both involve approvals, their purposes are sufficiently separated by their inputs and return values.

Naming Consistency3/5

The get_* prefix is used for three read tools, but lookup_agent, request_payment, and especially x402_fetch break the verb-first pattern. Names are readable and snake_case throughout, but the mix of get, lookup, request, and protocol-prefixed fetch is somewhat inconsistent.

Tool Count5/5

Six tools is a well-scoped size for a wallet/payment/x402 server. Each tool earns its place without redundant or superfluous operations.

Completeness4/5

The set covers the core lifecycle: account status, balances, transaction history, agent verification, direct payments, and paid resource fetching. Minor gaps exist, such as no explicit network listing or arbitrary token balance tool, but they are not essential for the stated purpose.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

OurPay WalletOAuth
io.github.Ourpay
Crypto wallet for AI agents: balances, payments, swaps and trading with owner controls.
Cryptocurrency Blockchain Web3 & Decentralized Tech
1
agtrepo-memory A
io.github.agtrepo
Encrypted, pay-per-use persistent memory storage for AI agents, gated by x402 payments on Base.
Knowledge & Memory Payments & Billing
61
AgentExec WebMCP & Base L2 Gateway A
io.github.Har50
Monetization and execution gateway for autonomous AI agents on Base Mainnet
Blockchain Payments & Billing Web3 & Decentralized Tech
41
Veyra A
io.github.zapxlabs
Give AI agents a wallet with a spending limit. Non-custodial USDC on Base, server-enforced limits.
Blockchain Cryptocurrency Web3 & Decentralized Tech
71

Related MCP Servers

Grip MCPofficial
Cryptocurrency Blockchain Payments & Billing
grip-foundation
A
license
A
quality
D
maintenance
Provides a non-custodial USDC wallet on Base for AI agents, with human-in-the-loop approval for every payment.
Updated 5 months ago (2026-04-28 03:20 UTC)
4
3 npm
MIT
cardzero-mcp
Blockchain Cryptocurrency Autonomous Agents
mrocker
A
license
A
quality
C
maintenance
Gives AI agents a smart-contract wallet on Base (USDC) with 10 stdio tools: create wallets, send USDC payments, pay x402-protected HTTP resources, and run ERC-8183 escrow Jobs for A2A service delivery.
Updated 5 months ago (2026-05-07 14:27 UTC)
10
5 npm
MIT
PipRailofficial
Payments & Billing Blockchain Cryptocurrency
piprail
A
license
A
quality
A
maintenance
A budget-bound x402 payment wallet for AI agents: it autonomously pays HTTP 402 payment-gated URLs across every major chain (EVM, Solana, and many non-EVM families). Self-custodial and backendless, your key, your RPC, with spend caps enforced before any on-chain send.
Updated 17 days ago (2026-09-10 13:19 UTC)
8
9
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 23 days ago (2026-09-04 10:54 UTC)
3
35 npm
MIT

Kura (蔵 — a storehouse that guards your treasures)

At a glance

Installation

(A) Homebrew

(B) Download the DMG directly

(C) Build from source

Updates

Uninstalling

First run

Funding (USDC)

Connecting AI (Claude)

The easiest way — the "AI Connect" screen in the app

Claude Desktop — one extension file is all you need

Claude Code · other MCP apps

If you're developing from source

How a payment flows

Security model

For developers

Tech stack

License · status

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Grip MCPofficial

PipRailofficial

token4u-mcpofficial