Loading ToolBench
Server-side EVM signing with AWS KMS and built-in DeFi protocol awareness. Expose your wallet to AI agents via MCP, CLI, or OpenClaw.
Agentic Vault defines 10 tools with complete input schemas and descriptions. All tools have clear, action-oriented names (vault_*) and non-empty descriptions. However, parameter descriptions lack depth and specificity. Most parameters have type declarations but many omit guidance on valid formats, ranges, constraints, or dependencies. Output schemas are not documented, the adapter converts WorkflowResult to text, but downstream agents don't know what fields to expect. Error handling is generic (denied/error states return reason text only, no recovery guidance). Security-sensitive tools (vault_send_transfer, vault_send_erc20_transfer, vault_sign_transaction) lack explicit permission checks or confirmation patterns. The composition is strong, tools are single-responsibility and produce outputs (addresses, balances) that can chain into downstream calls. Overall: solid foundation but falls short of production polish in parameter guidance, output documentation, and error recovery patterns.
Get the wallet address managed by this vault
Query native ETH or ERC20 token balance for an address
Check the health status of the vault signer
Send ERC20 token transfer after policy validation, sign and broadcast
Send native ETH transfer after policy validation, sign and broadcast
Sign a DeFi contract interaction after calldata decoding and policy validation
Output schemas not documented. Tools return WorkflowResult adapted to { content: [{ type: 'text', text: string }], details: undefined }, but LLMs cannot see the structure of WorkflowResult.data or the expected response format. This forces agents to parse unstructured text.
Parameter descriptions lack actionable constraints. Parameters like 'value' (wei), 'data' (hex calldata), and 'deadline' (unix timestamp) have type and semantic tags but no explicit format guidance. Example: 'value in wei (decimal string)' is present but lacks min/max bounds or examples of valid formats.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Sign an EIP-2612 permit after policy validation
Sign a Uniswap swap transaction after calldata decoding and policy validation
[UNSAFE] Sign a raw EVM transaction. Only available when enableUnsafeRawSign is configured.
Sign arbitrary EIP-712 typed data. Only available when enableUnsafeRawSign is configured.
No dry-run or confirmation pattern for irreversible operations. vault_send_transfer and vault_send_erc20_transfer (IRREVERSIBLE) and vault_sign_transaction (DESTRUCTIVE) lack explicit approval/confirmation steps. WorkflowContext may handle this internally, but the tool interface does not expose a confirm_before_execute or dry_run mode.
Error handling is opaque. Tools return denied/error states with a reason string, but provide no guidance on what the LLM should do next: retry, ask the user, or fail? No error categorization (retryable vs user-fixable vs fatal).
No explicit permission or scope declaration. Tools like vault_send_transfer and vault_send_erc20_transfer are destructive but do not declare required scopes (e.g., 'send:transfer', 'send:erc20'). This prevents least-privilege agent configurations.
EIP-712 domain/types/message parameters (vault_sign_permit, vault_sign_typed_data) are documented as 'object' with no nested schema details. LLMs cannot validate the structure of these complex nested payloads.