Loading ToolBench
An MCP server for wallet operations including ERC4626 vault interactions, cross-chain USDC transfers, and async vault administration using Lit Protocol
This server exhibits significant quality gaps across naming, descriptions, and schema completeness. Of 14 tools, only 2 (hex-to-decimal, decimal-to-hex) have explicit schema definitions visible in the source code. The remaining 12 tools are inferred from tool registration but lack visible input schema definitions in the provided codebase excerpts. Naming is inconsistent: some tools use verb_noun patterns (deposit-into, redeem-from, send-usdc) but many lack clarity on domain-specific operations. Descriptions are present but brief (18-35 characters) and lack context on when to use each tool, prerequisites, or expected outcomes. Parameters mention types and regex patterns but descriptions are minimal. No output schema documentation is visible. The server registers tools with Zod schemas internally but does not expose them in a queryable way for LLM planning. Error handling is generic (try/catch with error.message returns) without recovery guidance. The server is STDIO-only, limiting remote accessibility.
Retrieves the a list of owner assets
Accepts a pending deposit and swaps it for teller tokens
Accepts a pending redemption and swaps it for teller assets
Send assets from the owner wallet to the teller
Takes assets from the teller into the owner wallet
Updates the total USD value of the assets currently invested by the owner
12 of 14 tools lack visible input schema definitions in source code; schemas are inferred only from tool registration in index.ts. Cannot verify parameter types, constraints (regex patterns are documented in the spec but not shown in schema objects), or completeness.
Descriptions are extremely brief (18 - 45 characters). 'Deposit into a 4626 vault' does not explain what a 4626 vault is, what chain support exists, or when to use this vs other deposit tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Converts a decimal number to hexadecimal
Deposit into a 4626 vault
Get the allocations for a wallet in Base and Arbitrum
Converts a hexadecimal number to decimal
Receive USDC cross-chain using CCTP
Redeem from a 4626 vault
Send USDC cross-chain using CCTP
Gets the balance of a vault
No output schema documentation. Tools return { content: [...], isError: boolean } but agents cannot infer what content structure each tool returns (e.g., does vault-balance return a numeric balance, a formatted string, or a complex object?).
Parameter descriptions are missing or trivial. The provided spec shows regex patterns for addresses but the actual input schema Zod objects are not visible. Parameter descriptions should state format constraints inline (e.g. 'pkpEthAddress (Ethereum address, 0x-prefixed hex)').
Error handling is generic. Tools catch exceptions and return { content: [{ type: 'text', text: `Error: ${error.message}` }], isError: true }. Errors do not guide recovery (e.g., 'Chain not supported. Supported chains: ethereum, base, arbitrum.'); they do not categorize as retryable vs fatal; they do not suggest next steps.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible. Per spec, write operations like deposit-into-4626-vault should be marked destructiveHint=true; read operations should be marked readOnlyHint=true. This requires Zod schema metadata or explicit tool definition hints, which are not shown in the provided source.
Private key is stored in environment variable (ETH_CREDITS_NFT_PRIVATE_KEY) and used directly in src/lit/tool.ts. While credentials are not passed as tool parameters (good), the private key should be protected with stronger access controls, key rotation policies, and audit logging. The executeTool function is not shown but uses this key to sign transactions, no rate limiting or per-call authorization is visible.
Naming inconsistency and lack of verb clarity for administrative tools. 'async-vault-fulfill-deposit' and 'async-vault-fulfill-redeem' use 'fulfill' instead of clearer verbs like 'accept_deposit' or 'confirm_deposit'. 'async-vault-update-invested' is vague, does it increment, set, or calculate the invested amount?