Loading ToolBench
MCP Server for AgentWallet Protocol — AI agents get wallets, escrow, and payments as native tools
AgentWallet MCP server has 13 tools with clearly defined names following verb_noun convention (create_agent, get_wallet, transfer_token, etc.). All tools have descriptions and input schemas are present. However, several critical quality gaps reduce the overall score: (1) Parameter descriptions lack detail on constraints, formats, and ranges, e.g., 'status' filter in list_agents lacks enum values; token_symbol in transfer_token states 'USDC or USDT' as prose rather than enforced enum; (2) Output schemas are not documented, tools return data but the structure is inferred rather than explicitly defined; (3) Error handling guidance is absent, no recovery paths or classification for irreversible operations despite three IRREVERSIBLE tools (transfer_token, transfer_sol, batch_transfer); (4) No idempotency guarantees despite providing idempotency_key parameters, descriptions do not confirm idempotent behavior; (5) Security concerns: no audit trail documentation, no permission gate descriptions, no scope declarations despite managing funds.
Send SOL to multiple recipients in a single operation. Each transfer is policy-enforced independently.
Register a new AI agent and automatically create its Solana wallet. Returns agent details including wallet address.
Create a new Solana wallet. Optionally link to an agent. Returns wallet address.
Get details of a specific agent by ID, including status, reputation, and wallet info.
Get SOL and SPL token balances for a wallet. Returns SOL balance and all token holdings.
Get all supported token balances (USDC, USDT) for a wallet, plus SOL balance.
Output schemas not documented. Tools return data (agent details, wallet info, balances, transaction signatures) but the structure of responses is not specified. LLMs cannot plan downstream tool chains or extract required fields without explicit response documentation.
Irreversible operations (transfer_token, transfer_sol, batch_transfer) lack error handling guidance, confirmation/dry-run patterns, and recovery paths. No documentation of what happens on partial failure (e.g., batch_transfer succeeds for some recipients but fails for others). Agents cannot safely execute financial transactions without clear failure modes and recovery options.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-04-07 | F | 23 | - | v1 |
Get wallet details including address and active status.
List all registered AI agents. Optionally filter by status (active/paused/suspended).
List all supported stablecoins with their mint addresses and decimals.
List all wallets. Optionally filter by agent or wallet type.
Send SOL from an agent wallet to a destination address. Enforces spending policies, deducts platform fees, and creates an audit trail. Returns transaction signature.
Send USDC or USDT from an agent wallet to a destination address. Enforces spending policies, deducts platform fees in SOL, and creates an audit trail.
Update an agent's name, description, capabilities, or status.
Parameter constraints not enforced via enum/pattern. 'status' in list_agents accepts free-form strings instead of enum ['active','paused','suspended']. 'token_symbol' in transfer_token states 'USDC or USDT' as prose description rather than enforced enum. 'wallet_type' in create_wallet has prose 'agent, treasury, or fee' instead of enum. LLMs will hallucinate invalid values.
No idempotency guarantees documented. transfer_token and transfer_sol accept 'idempotency_key' parameters but descriptions do not confirm that repeated calls with the same key return the same result without side effects. Agents cannot safely retry without risking duplicate transactions.
Security scope and permissions not declared. Tools manage financial wallets and irreversible transfers but do not state required permissions (e.g., 'read:wallet','write:wallet','transfer:funds'). No audit trail documentation despite needing compliance-grade logging for financial operations. No permission gate descriptions to explain which users/agents can call transfer_token.
Parameter format and validation rules not specified. 'to_address' in transfer_token and transfer_sol is documented as 'Solana address (base58)' but lacks length, character set, or checksum format details. Agents cannot validate input before calling. 'amount' parameters lack min/max bounds, transfer_token accepts 'number' with no range check.
List operations lack pagination documentation. list_agents and list_wallets accept 'limit' and 'offset' but descriptions do not explain max page size, total count return field, or cursor format. No guidance on when to use offset vs cursor-based pagination. Large result sets could exhaust context window.
Error recovery guidance absent. No tool descriptions explain what the LLM should do if a call fails. E.g., if transfer_token fails with 'insufficient balance', should the agent retry, call get_balance first, or report to user? No actionable error messages.