This MCP server exposes three blockchain wallet tools with critically poor definition quality. All three tools have minimal descriptions that lack clarity on execution flow, prerequisites, and consequences. Parameter descriptions are entirely absent despite required parameters existing. No output schemas are documented. Most critically, two tools (deleteUserWallet, exportWalletPrivateKey) handle extremely sensitive operations (wallet deletion, private key export) yet lack proper safeguards, confirmation patterns, or detailed security guidance in their definitions. The descriptions are generic and do not meet the 10-1024 character guidance or LLM-optimization standards. Tool naming is acceptable but insufficient without proper schema and description support.
Before using the function, ask the user for additional confirmation. Proceed with deletion or execution only after the user explicitly approves the request.
Private key export tool has no security warnings, secret handling guidance, or documentation of how returned secrets should be managed. Violates pattern:secret-injection.
Parameter descriptions are either missing or trivial. 'User address' (11 chars) does not explain format, constraints, or validation rules. LLMs cannot infer whether to pass '0x123abc' or 'wallet_name' or 'user@example.com'.
Recommendations
Add comprehensive output schemas for all three tools in the MCP tool registration. Document all returned fields, their types, and what they represent. Example: getUserWalletList should return {wallets: [{address: string, name?: string, balance?: string, ...}], total: number, nextCursor?: string}
Rewrite tool descriptions to follow LLM-optimization guidelines: State WHAT the tool does, WHEN to use it, and WHAT it returns. Target 50-200 characters. Example: deleteUserWallet: 'Permanently delete a user wallet. IRREVERSIBLE, call only after user confirms. Requires valid wallet address. Returns confirmation with timestamp.'
Add explicit parameter descriptions for 'userAddress' across deleteUserWallet and exportWalletPrivateKey. Specify: format (e.g., '0x-prefixed 42-char hex string'), validation rules, and examples of valid/invalid inputs. Example: 'Ethereum wallet address in format 0x[40-char hex]. Case-insensitive. Example: 0x742d35Cc6634C0532925a3b844Bc9e7595f42e0E'
Implement confirmation pattern for destructive operations. deleteUserWallet should return a dry-run response first asking for explicit user confirmation before executing deletion. Use Multi Round-Trip Request (MRTR) with result: 'input_required' to wait for user approval.
Add security warnings to exportWalletPrivateKey description: 'WARNING: Exported private keys can be used to steal all funds in the wallet. Return immediately to user, do not log, store, or process further. User alone must secure the key.' Document that the response must NOT be logged.
deleteUserWallet description reads like an instruction manual ('Before using the function, ask the user...') instead of a tool definition. Mixes agent protocol concerns into the description field.
Tool descriptions do not state operational consequences. 'Delete' and 'Export' are actions with irreversible side effects, descriptions must explicitly warn of this and provide recovery guidance.
No error handling or recovery guidance documented. How should an LLM respond if the address is invalid, wallet not found, or operation fails? No guidance provided.
getUserWalletList has no pagination or result limit guidance. If a user has hundreds of wallets, the tool will return all, potentially exhausting context or timing out.
getUserWalletList
Add pagination support to getUserWalletList. Accept parameters: limit (default 20, max 100), offset or cursor. Return total count and next_cursor for pagination. Document in the tool description: 'Returns up to 20 wallets per call. Use cursor to fetch additional results.'
Document error cases for all tools. Example: deleteUserWallet should document: 'If wallet not found, returns 404 with available wallet addresses. If user lacks permission, returns 403 with required scope. Retry-safe: only fails before state change.'
Add permission/scope documentation. Clarify which of these operations require authentication scope (e.g., 'wallet:delete', 'wallet:export') and how agents should handle permission denied errors.
Use tool annotations (destructiveHint, readOnlyHint, idempotentHint) in MCP 2026-07-28. Mark deleteUserWallet as {destructiveHint: true}, exportWalletPrivateKey as {destructiveHint: true}, getUserWalletList as {readOnlyHint: true}.
Separate concerns: if confirmation is required, implement a two-step pattern: deleteUserWallet_preview (returns wallet info for confirmation) + deleteUserWallet_confirm (takes confirmation token). Do not bake confirmation logic into descriptions.