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), 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 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.

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

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 network, that chain's USDC) in the wallet app, then re-requests the same URL with the payment header to return the content. If no payment is required (no 402), it just returns the body. 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), memo (what the payment is for — the user reads it to decide). 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). 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. 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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a clearly distinct capability: balance reading, wallet/account state, transaction history, initiating payments, x402 paid fetches, and ERC-8004 agent lookup. The only mild adjacency is get_balances vs get_wallet_status, but their descriptions clearly separate numeric balances from wallet/account state.

Naming Consistency4/5

Five of six tools follow a clean snake_case verb/noun pattern (get_balances, get_wallet_status, get_history, request_payment, lookup_agent). x402_fetch breaks the verb-first convention by leading with a protocol name, a minor deviation that is still readable.

Tool Count5/5

Six tools is well-scoped for a wallet/payment server, with each tool earning a distinct place (three read tools plus three action/lookup tools). Nothing feels redundant or padded.

Completeness4/5

The surface covers the core wallet lifecycle: check state, read balances, review history, request payments, pay for x402 resources, and verify agent identity. Gaps are deliberately out of scope (account switching and limits are user-only in the app), so no dead ends for an agent's expected workflow.

Maintenance

ActivityActive
ResponsivenessUnresponsive