algotool has 23 tools with consistent naming conventions and decent descriptions. All tools start with action verbs (wallets_, send_, asa_, app_, inspect_, get_, list_) which is strong. Descriptions are present for all tools and generally informative (average ~100 chars). However, there are critical gaps: (1) NO output schemas are documented anywhere, LLMs cannot know what fields to expect from results; (2) Many parameter descriptions are terse (e.g., 'Wallet index' lacks context on valid range or what wallet indices mean); (3) No error handling guidance visible in any tool, failures will leave agents without recovery paths; (4) No tool annotations (readOnlyHint/destructiveHint) despite obvious risk categories visible in the spec sheet; (5) Several high-risk tools (wallets_clear, wallets_export, send_algo, batch_send) lack confirmation/dry-run patterns. Parameter schemas are present and properly typed for most tools, which is a strength. The server exposes sensitive operations (wallet mnemonics, destructive clears, batch fund transfers) without documented safeguards.

• Add explicit output schemas for all 23 tools in the tool definitions. Example: 'Returns an object {wallets: [{address, index, balance}], total}'. This lets LLMs chain tools with confidence.
• Document error scenarios and recovery paths. E.g., 'send_algo: If balance is insufficient, returns error 'Insufficient ALGO balance. Current: X, required: Y.' Try fund_wallets to increase balance.' or 'If address is invalid, call wallets_list to get valid addresses.'
• Add tool annotations to the MCP server: mark wallets_clear, send_algo, batch_send as {destructiveHint: true}; mark wallets_list, asa_info, get_balance as {readOnlyHint: true}; mark idempotent read ops as {idempotentHint: true}. See MCP spec 2026-07-28 for syntax.
• Implement a confirmation pattern for destructive ops: add optional 'confirm=true' parameter to wallets_clear and send_algo (require explicit confirmation), or return a separate 'confirm_delete' or 'confirm_send' tool that must be called before the actual operation.
• Expand parameter descriptions with constraints and examples. E.g., 'wallet_index: 0-based integer index of the wallet to use. Get valid indices from wallets_list(). If index is out of bounds, returns error listing available indices.'
• Split polymorphic 'address' parameter: change account_history(address: string|number) to account_history_by_address(address: string) and account_history_by_wallet_index(wallet_index: number). This makes the LLM's choice explicit and reduces errors.
• Clarify the distinction between send_algo (one-to-one), fund_wallets (one-to-many distribution to all wallets), and batch_send (all-to-one aggregation). Add notes like: 'send_algo: single ALGO transfer. fund_wallets: distribute from wallet X to all other wallets. batch_send: send from ALL wallets to one address.'