Loading ToolBench
Kura MCP adapter — AI agents (MCP) and humans (CLI) query and pay with local wallets on Base Sepolia and Arc blockchains. Supports balance checks, transaction history, direct payments, and x402 paid resource fetching with EIP-3009 signatures.
kura-mcp has 6 tools with clear action verbs (get_*, request_*, lookup_*) and moderately detailed descriptions. However, there are significant gaps in schema completeness and parameter documentation. Most tools lack explicit input schema visibility in the provided source code, and descriptions, while domain-specific and helpful, fall short of the LLM-optimized 50-200 character baseline. Error handling guidance is minimal, tools do not explain recovery paths or categorize errors. Output schemas are not documented. The server demonstrates good intent (domain clarity, security awareness via risk labels) but lacks the rigor expected of production-grade tools.
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.
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).
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.
Queries the ERC-8004 Identity Registry smart contract on-chain to read an agent's registered wallet address and resource domain. Returns agent details if found, or an error if the agent number does not exist. Arguments: agent_id (the agent's ERC-8004 number), pay_to (optional address to compare against the agent's registered wallet), resource (optional resource URL whose domain is compared with the domain listed on-chain).
Input schemas for tools 1 - 2 are empty objects ({}); no parameter validation declared
Output schemas are not documented anywhere in the codebase. LLMs cannot infer what fields each tool returns or their types, forcing trial-and-error exploration.
No error categorization or recovery guidance. Tools do not tell LLMs whether errors are retryable, user-fixable, or fatal. E.g., 'Errors if there is no wallet' (get_balances) but no hint on how to proceed.
request_payment and x402_fetch accept agent_id as optional integer but lack validation constraints (range, format). LLM could pass 0, negative, or extremely large values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
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 on its agent card or documentation).
Fetches a paid x402 resource. The wallet app opens an approval window for the payment. Once the user approves with their password, the resource is fetched and returned. Arguments: url (the paid resource URL), memo (what the payment is for — the user reads it in the approval window, so always fill it in), and optionally agent_id (the seller's ERC-8004 number, if you know it from the service's own documentation or agent card).
lookup_agent pay_to and resource parameters are optional but lack format/validation guidance. pay_to description says 'address' but does not specify the 0x42-character constraint visible in request_payment description.
get_history limit parameter lacks min/max bounds. Default is 20, max is 200, but neither is enforced in the schema, only documented in the description. LLM could request 999 entries.
request_payment token parameter accepts 'USDC' or 'ETH' but this is stated only in the description, not as an enum in the schema.
Tool descriptions mention domain-specific state terms (e.g., 'sent, blocked, failed, signed, settled' for get_history) but do not explain the business logic behind state transitions. When should an LLM expect 'settle_failed' vs 'failed'?