Skip to main content
Glama
dinggi5

Kura

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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.

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), settle_failed, unknown (a signed transaction was submitted but the wallet couldn't confirm the chain received it — detail is its tx hash; it may have gone through, so never resend on the strength of this entry alone; the wallet app later rechecks it on-chain and turns it into sent or reverted), reverted (mined but reverted on-chain — no money moved, only gas), expired (an x402 signature that was never used before it expired — no money moved), or received (money that came in — to is the sender, detail the tx hash; both are empty for ETH a contract sent; found on-chain by the wallet app while it runs, back to 90 days). Use limit to cap how many come back (default 20).

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.

lookup_agentA

Reads an agent's ERC-8004 record from the registry on the active 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.

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, tx_hash, detail, and an explorer link. status is approved (the chain accepted the transfer), rejected or failed (nothing was sent — safe to ask again), or unknown: the user approved but the wallet couldn't confirm whether the transfer reached the chain (tx_hash is set when known). unknown means it MAY have been sent — never ask again on your own; tell the user and have them check the history or the tx.

x402_fetchA

Calls an x402 paid API or URL. It sends the request first — GET by default, or the given method (POST, PUT, PATCH, DELETE) with optional headers and a JSON object body; if the server answers 402 Payment Required, it asks the user to approve the required payment (exact scheme, the active network, that chain's USDC) in the wallet app, then sends the SAME request (same method, headers and body) again with the payment header and returns the content. If no payment is required (no 402), it just returns the response. Redirects are not followed once a payment header is attached (nor at all when method, headers or body are given) — a redirect comes back as an error with the new address. Text and JSON come back in body. Binary responses (images, PDF, audio) are saved to a file whose path is in saved_file (with content_type); a PNG/JPEG/GIF/WebP image up to 3 MB is also attached as an image. Text longer than 100,000 characters is cut in body and kept whole in saved_file. If saving takes too long (macOS asking for Downloads access), the result comes back first and saving_file names where the file will appear. Settlement takes one of two shapes, chosen by the server's requirement: a facilitator settles the signed EIP-3009 authorization (no gas from this wallet), or — where gas is paid in USDC itself and the server asks for eip3009-client-broadcast — the wallet broadcasts the transfer itself, so the price AND its gas leave this balance. 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), method, headers, body (JSON object), memo (what the payment is for — the user reads it to decide), agent_id. Returns: payment, paid, status, http_status, body, and amount/pay_to/settlement when paid; on a chain where the wallet broadcasts the payment itself, tx and explorer point at that transaction (both are empty on the facilitator-settled path, where settlement_tx/settlement_explorer carry the transaction the seller reports in its receipt — the seller's word, not checked on-chain by the wallet). IMPORTANT — decide on payment, which says where the money is: "none" = nothing was paid, trying again is safe (declined, no 402, or "reverted": the chain rejected the transfer and only gas was spent); "confirmed" = the money left the wallet; "unknown" = it MAY have left (status pending/unknown, or settlement_failed on the facilitator path, where the server's refusal doesn't prove the facilitator didn't settle). For confirmed and unknown without content, asking again can pay a second time — stop and tell the user, showing the tx (when a tx came back without content, x402_resubmit re-sends its proof without paying again). paid is kept for older callers and is simply payment != "none". Read notice when present, and never retry on an HTTP status alone: after the money moved the server may answer with a fresh 402 challenge that reads as if the payment never happened.

x402_resubmitA

Resubmits the on-chain proof of an x402 payment this wallet already broadcast itself, to get the content it paid for. Use it when x402_fetch returned a tx without content (status pending, unknown or undelivered, or settlement_failed with a tx). No new money moves and no approval is asked: the wallet re-sends the same proof (the tx plus the saved challenge values) to the same URL. It first checks the tx on-chain — if it isn't mined yet you get status pending (wait and call again), if it reverted you get reverted (payment none: nothing was paid, so paying again is a new decision). Sellers keep proofs acceptable only for a while (the reference server: 10 minutes), so a late resubmit can be refused — that is settlement_failed with a notice; do not pay again then, tell the user and show the tx. Proofs are kept for 7 days. Returns the same shape as x402_fetch.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.3/5.0

Scored across 7 tools

Disambiguation4/5

Most tools are clearly distinct (request_payment, get_wallet_status, get_balances, get_history, lookup_agent). The only partial overlaps are request_payment vs x402_fetch (both trigger payments) and x402_fetch vs x402_resubmit, though the descriptions clearly delineate direct transfer vs paid API call vs proof resubmission without new money.

Naming Consistency4/5

Consistent snake_case verb_noun pattern (request_payment, get_wallet_status, get_balances, get_history, lookup_agent), with x402_fetch and x402_resubmit using a coherent namespace prefix. Minor deviation from pure verb_noun but overall predictable.

Tool Count5/5

7 tools is well-scoped for a wallet/payment server, with each tool earning its place. No redundant or filler tools.

Completeness4/5

Covers the core wallet lifecycle: payments, status/accounts, balances, history, x402 paid fetches with resubmission, and agent registry lookup. Minor gaps like account-switching (explicitly user-only) or explicit cancellation are reasonable omissions, but no major workflow dead ends.

Maintenance

ActivityActive
ResponsivenessUnresponsive