Server defines 6 tools with complete input schemas and descriptions. Naming follows verb_noun convention (clavion_transfer, clavion_balance). Descriptions are present (avg ~120 chars) and explain what each tool does and its risk level. However, descriptions lack actionable context for LLM selection (e.g., when to use transfer vs swap, prerequisites, recovery guidance). Parameter descriptions are minimal (1-2 words). No output schemas documented. Error handling and recovery guidance absent. Security-critical tools (transfer, approve, swap) lack confirmation/dry-run patterns despite being irreversible. No tool annotations (destructiveHint, idempotentHint) despite high-risk operations.

• Add output schemas to all tools. Document the structure of successful responses (e.g., clavion_transfer returns {txHash, status, gasUsed, blockNumber}). This enables LLMs to chain tools and extract required fields.
• Implement a confirmation/dry-run pattern for irreversible operations. Add optional 'simulate' or 'confirm' parameters to transfer, approve, and swap tools. Return a preview of consequences before execution.
• Add tool annotations to the MCP server registration: mark transfer/transfer_native/approve/swap with destructiveHint=true; mark balance/tx_status with readOnlyHint=true. This signals intent to LLMs without requiring description parsing.
• Expand parameter descriptions to include format, range, and constraints. E.g., 'amount' → 'Amount to transfer in token units (decimal string, e.g. "1.5", no limit on precision)'. 'chainId' → 'Blockchain chain ID (1=Ethereum, 137=Polygon, 42161=Arbitrum)'.
• Document error scenarios and recovery paths. E.g., 'If policy check fails, the error will include the violated rule. Retry with a lower amount or contact the policy administrator.' Add these to tool descriptions.