CRITICAL: Private keys exposed as tool parameters. evm_approve_nft, evm_set_approval_for_all, evm_approve_token all accept 'privateKey' as required string parameters. This violates pattern:secret-injection, agent call logs will contain private keys, risking exposure via trace logging, error messages, or prompt history.

Two tools reference non-visible implementation files. evm_list_tools_by_category and evm_search_tools point to 'check_mbss.js' rather than TypeScript source files. Actual input schemas and implementations cannot be verified.

No output schemas documented. All 8 tools lack explicit documentation of what fields they return. Agents cannot plan downstream calls or extract required data.

Parameter relationships not documented. evm_approve_nft has a 'tokenId' field that becomes optional when 'approveAll' is true, but no description states this dependency. evm_find_bridge_routes has a 'preferences' object with conditional logic (speed/security apply only when available), but implications are not explained.

Address and token ID format constraints missing. Parameters like 'contractAddress', 'spender', 'owner', 'operator' lack format hints (e.g., '0x...' Ethereum addresses). 'tokenId' lacks specification (numeric string? hex? decimal?). This forces LLMs to guess at valid formats.

No error handling guidance. None of the 8 tools document what errors can occur or how to recover. For state-changing tools (evm_approve_nft, evm_set_approval_for_all, evm_approve_token), no guidance on retry logic, insufficient gas, invalid addresses, or already-approved states.

Naming conflicts and unclear distinctions. evm_approve_nft and evm_set_approval_for_all both approve, but the distinction (single token vs operator) is not obvious from names.

Missing state-change warnings. evm_approve_nft, evm_set_approval_for_all, and evm_approve_token are all irreversible write operations, but descriptions do not warn agents of this.

Incomplete schema for evm_approve_token. Amount parameter accepts string with hint 'unlimited' but no enum or validation pattern. LLMs could pass invalid values like 'max', 'all', or malformed decimals.

evm_find_bridge_routes preferences object lacks practical documentation. What does 'instant' vs 'fast' mean in real time? What are the throughput/cost differences? Agents cannot reason about tradeoffs without this context.